Content-Security-Policy: The Header That Stops Most XSS Attacks Cold

Cross-site scripting has been breaking websites for a quarter century, and it keeps working for one structural reason: by default, the browser trusts whatever the page tells it. If an attacker can inject a script tag, the browser executes it. No questions asked.

Content-Security-Policy flips that contract. Instead of executing everything the document contains, the browser enforces an allow-list you define: these sources may load scripts, these may load styles, nothing else runs — no matter how it got into the page. It is the closest thing to an XSS vaccine, because it keeps protecting you after your input filtering misses one case. And almost every site that gets compromised through XSS either has no CSP or has one with a hole big enough to drive a payload through.

What CSP actually does

CSP is delivered as a single response header containing a set of directives. Each directive governs a resource type and lists the sources allowed to provide it:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.net; object-src 'none'; base-uri 'self'; frame-ancestors 'self'

With that policy in place, a browser will refuse: a script tag pointing at evil.example (not in script-src), a Flash-like object embed (object-src 'none'), a base tag hijacking relative URLs (base-uri 'self'), and another site framing your page (frame-ancestors 'self').

The critical property is that this enforcement happens inside the browser, on every page load, against the final document — so it catches injections your server-side filters missed, DOM-based XSS that never touches your backend, and third-party widget compromises. Your filter has to be right every time; the policy only has to be strict once.

The directives that earn their keep

Start from default-src 'self' and open only what breaks. Directives you omit fall back to default-src, so a strict default with explicit exceptions is both safer and easier to audit than a patchwork.

Inline scripts: the problem and the two real solutions

Here is where most CSPs die. A huge share of real-world sites have inline scripts — analytics snippets, framework hydration code, that marketing tag someone pasted into the template in 2024. A strict script-src blocks them all, the site visibly breaks, someone adds unsafe-inline, and the policy becomes decorative: unsafe-inline allows every inline script, including the attacker's.

There are two legitimate ways out.

Nonces. On every response, generate a random value, put it in the policy (script-src 'nonce-r4nd0m...'), and stamp each of your inline scripts with the same value:

<script nonce="r4nd0m...">/* your code */</script>

The browser runs inline scripts only when the nonce matches. Injected script tags without the nonce are refused. The nonce must be fresh per response and cryptographically random — a hardcoded "nonce" is just unsafe-inline with extra steps.

Hashes and strict-dynamic. For script files you control, you can pin the hash of trusted code. For modern setups, strict-dynamic lets a trusted script (one with your nonce or hash) load its own dependencies transitively, so you do not have to enumerate every lazy-loaded chunk. Together they are the current best practice: 'strict-dynamic' plus a nonce, with host allow-lists demoted to legacy-browser fallback.

What you cannot do responsibly: keep unsafe-inline "temporarily." Policies with unsafe-inline provide near-zero XSS protection and still create compliance paperwork.

frame-ancestors: the modern clickjacking defense

Framing attacks (clickjacking, UI redressing) are covered by the X-Frame-Options header, but XFO predates CSP and only understands DENY and SAMEORIGIN. frame-ancestors supersedes it: it supports full source expressions, applies to all framing contexts, and is respected by every current browser. Use both — XFO for legacy clients, frame-ancestors as the real control — but know that frame-ancestors is the one doing the work. 2MNY's header audit treats a missing or misconfigured frame-ancestors as a finding in its own right, and its clickjacking module goes further: it actually attempts to frame your page in a headless browser and proves whether the protection holds.

Rolling out without breaking production

CSP has a deserved reputation for breaking sites when introduced carelessly. The fix is the staged rollout the spec designers built for exactly this purpose:

1. Ship Content-Security-Policy-Report-Only first with the policy you want to have. Report-Only evaluates violations and reports them to your endpoint without enforcing anything.
2. Collect and fix violations. Each report names the directive and the blocked resource. Add legitimate sources, add nonces to your inline code, remove what turns out to be dead third-party code.
3. When reports go quiet, enforce. Flip to the real Content-Security-Policy header. Keep a report-uri (or report-to) in the enforced policy so new violations surface after changes.
4. Re-test after every feature release. The classic CSP failure mode is a six-month-old strict policy quietly broken by one new marketing tag.

How to check where you stand

Read your headers: open developer tools, inspect the response for your homepage and one authenticated page (policies often differ, and the authenticated one matters more). Look for unsafe-inline in script-src, wildcards like https: (which allows every HTTPS host on earth), and the absence of frame-ancestors, object-src, and base-uri.

Then run a proper scan — the free tier at 2mny.com grades CSP as part of its header security audit: it parses the policy, flags the directives that undermine it, checks whether report-only mode has been left on indefinitely, and cross-references your third-party scripts for subresource integrity. For the underlying attack class, the XSS scanner explainer covers how detection actually works, and the cookie security guide completes the picture on the storage side of browser defenses.

CSP will not make XSS impossible. It makes XSS conditional — conditional on the attacker also compromising a source you allow, which is a much harder problem than pasting a payload into a comment box. In a world where the average site runs scripts from a dozen origins, that conditional is the difference between an incident and a log entry.