Toolypet

Content Security Policy: Your XSS Kill Switch

Why CSP Is the #1 XSS Defense

Cross-Site Scripting (XSS) remains the most common web vulnerability, appearing in OWASP's Top 10 every year since 2003. Traditional defenses (input sanitization, output encoding) are necessary but insufficient — a single missed escape in thousands of templates can open the door. CSP provides a browser-enforced allowlist: even if an attacker injects a script tag, the browser refuses to execute it because the source isn't in the policy. Think of it as a firewall for your DOM.

Anatomy of a CSP Header

default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src *; object-src 'none'

Each directive controls a resource type. default-srcis the fallback — if a specific directive isn't set, the browser uses default-src. script-src is the most critical: it controls where JavaScript can load from. object-src 'none' disables Flash/Java plugins (a common attack vector). The key principle: start restrictive, loosen only when needed.

The unsafe-inline Problem

Adding 'unsafe-inline'to script-src effectively disables CSP's XSS protection because inline scripts are exactly what attackers inject. The modern alternative is nonce-based CSP: your server generates a random nonce per request, adds it to the CSP header (script-src 'nonce-abc123'), and your legitimate script tags include nonce="abc123". Attacker-injected scripts won't have the nonce and will be blocked.

Deployment Strategy: Crawl, Walk, Run

Step 1 (Report-Only): Deploy with Content-Security-Policy-Report-Only to collect violations without breaking anything. Monitor for 1–2 weeks. Step 2 (Enforce + Permissive): Switch to enforcing mode with a permissive policy based on observed traffic. Fix violations as they appear. Step 3 (Strict): Tighten to the minimum necessary sources. Remove unsafe-inline/eval. Add frame-ancestors to prevent clickjacking. A well-deployed CSP reduces your XSS attack surface by an estimated 90%+.

Frequently Asked Questions

What is the difference between the HTTP header and the meta tag?

The HTTP header is set by the server and is the recommended approach — it covers the entire page lifecycle and supports all directives. The HTML meta tag (<meta http-equiv="Content-Security-Policy">) is useful for static hosting where you can't control headers, but it doesn't support frame-ancestors, report-uri, or sandbox directives.

How do I handle third-party scripts (analytics, ads)?

Add their specific domains to script-src (e.g., script-src 'self' https://www.googletagmanager.com). Avoid using wildcard (*) for script-src — it defeats the purpose of CSP. For analytics that inject inline scripts, use nonce-based or hash-based allowlisting. Some providers (e.g., Google Tag Manager) publish CSP-compatible integration guides.

What does default-src 'none' mean?

It blocks all resource loading by default. You then explicitly whitelist only what you need: script-src, style-src, img-src, etc. This “deny-all, allow-specific” approach is the most secure starting point. Any resource type you forget to explicitly allow will be blocked, which surfaces misconfigurations immediately rather than silently failing.