Content Security Policy (CSP): A Practical Guide to Stop XSS Attacks

Without CSP, a browser will execute any JavaScript it encounters on your page, whether you put it there or an attacker injected it. With CSP, the browser blocks anything not explicitly allowed by your policy.

Why CSP Matters

XSS is the most common web vulnerability. It lets attackers: - Steal session cookies and hijack user accounts - Redirect users to phishing pages - Inject cryptominers that use your visitors' CPUs - Deface your website with malicious content - Exfiltrate data from forms and pages

CSP does not just detect XSS — it prevents it at the browser level.

CSP Basics

A CSP header looks like this:

Key Directives

Source Values

Step-by-Step Implementation

Step 1: Start with Report-Only Mode

Do not jump straight to enforcing CSP. Start by monitoring what would be blocked:

This logs violations without blocking anything. Check your server logs or a CSP reporting service to see what would break.

Step 2: Build Your Base Policy

Start strict and add exceptions:

Step 3: Add Your CDNs and Services

If you use Google Fonts, Analytics, Stripe, etc., add them:

Step 4: Handle Inline Scripts with Nonces

Instead of using 'unsafe-inline' (which weakens CSP), use nonces:

The nonce must be cryptographically random and different on every page load.

Step 5: Switch to Enforcement

Once you have confirmed no legitimate resources are blocked, remove Report-Only:

Server Configuration Examples

Nginx

Apache

Next.js (next.config.js)

Common Mistakes

1. 1Using `'unsafe-inline'` and `'unsafe-eval'` everywhere — This basically disables CSP protection. Use nonces instead.
2. 2Setting `default-src *` — This allows everything and defeats the purpose.
3. 3Forgetting `object-src 'none'` — Flash and Java applets are attack vectors.
4. 4Not testing in report-only mode first — You will break your site.
5. 5Setting CSP once and forgetting — New third-party scripts need to be added to the policy.

Check Your CSP

Run a ZeriFlow scan to instantly check if your website has a Content Security Policy header and how well it is configured. The scan evaluates your CSP along with 80+ other security checks.

Conclusion

Content Security Policy is the most powerful browser-side defense against XSS. Start with report-only mode, build your policy gradually, use nonces instead of unsafe-inline, and test regularly. Your users' security depends on it.

Further Reading

• OWASP Content Security Policy Cheat Sheet
• RFC 6797 — HTTP Strict Transport Security (HSTS)
• OWASP Top 10 Web Application Security Risks

<!-- zf-internal-links -->