What Is a CSP Header? Content Security Policy Explained

A Content-Security-Policyheader is an allowlist the server sends and the browser enforces. It names, directive by directive, which sources are permitted to supply which kind of content — scripts from this origin, styles from that one, images from anywhere, network requests only back to your own API — and the browser refuses to load or execute anything that falls outside the list. Nothing about content security policy is advisory: a script tag pointing at a source not on the allowlist doesn't get a warning in the console and run anyway, it simply doesn't execute.

That enforcement point is what makes CSP worth the setup cost. Most security headers describe a preference — do this over HTTP, don't frame this page. CSP is closer to a firewall rule for a single page's content sources, applied by every browser that loads it, with no server-side trust required after the header is sent.

CSP's reason for existing is cross-site scripting, and it's worth being precise about what it does and doesn't do there. It does not prevent an attacker from injecting a <script> tag into your page through a stored or reflected XSS bug — an unescaped comment field, a template that echoes a query parameter back into HTML, any of the usual ways user input ends up rendered as markup. Fixing that injection point is still the actual fix, and CSP is not a substitute for input sanitization or output encoding.

What a strict CSP does is make the injected script harmless on arrival. If script-src doesn't allow inline scripts and doesn't allow the attacker's source, the injected tag sits in the DOM and never runs. The browser parses it, sees it doesn't satisfy the policy, and drops it. This is the defense-in-depth argument for CSP in one sentence: it doesn't stop the injection, it stops the injected code from executing — a second, independent line of defense that holds even when the first one (clean input handling) has already failed somewhere in the codebase.

Here's a realistic policy for a page that serves its own scripts and styles, loads images from a CDN, and calls its own API:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0mBase64'; style-src 'self' 'unsafe-inline'; img-src 'self' https://cdn.example.com data:; connect-src 'self' https://api.example.com

• default-src 'self'— the fallback for any directive type not listed explicitly. Fonts, media, workers and anything else without its own rule fall back to this one, so it's the baseline the rest of the policy narrows or widens from.
• script-src 'self' 'nonce-r4nd0mBase64'— the most security-critical directive, since it's the one that decides whether an injected <script> tag can run at all. This policy allows scripts served from the same origin plus one specific inline script tagged with a matching nonce attribute — nothing else.
• style-src 'self' 'unsafe-inline' — same-origin stylesheets, plus inline style attributes and <style> blocks. Inline styles are a much smaller attack surface than inline scripts, which is why 'unsafe-inline' shows up here far more often than on script-src.
• img-src 'self' https://cdn.example.com data: — images from the same origin, a named CDN, and data:URIs (inline base64 images), a common allowance since images can't execute code the way scripts can.
• connect-src 'self' https://api.example.com — the directive that restricts fetch, XMLHttpRequest, WebSocket and EventSource targets. This is the one that catches exfiltration: even a successfully injected script that runs under a permissive script-src still can't send stolen data anywhere connect-srcdoesn't allow.

The keyword values are worth knowing on sight. 'self' means same origin only — same scheme, host and port as the page. 'unsafe-inline' allows inline scripts or styles with no further check, which is exactly as broad as it sounds; a lot of real sites still ship it on script-src because migrating away from inline event handlers and inline <script> blocks is real refactoring work, not a header change. 'nonce-...' and 'sha256-...' are the safer alternative: a nonce is a random value generated fresh per response and matched against a nonceattribute on the script tag, while a hash allowlists a specific script's exact content. Both let a specific inline script run without opening the door to every inline script an attacker might inject.

Shipping a strict CSP directly to production is how a page ends up with broken analytics, a dead payment widget, or fonts that silently stop rendering — because some third-party script the team forgot about needed a directive that wasn't on the list. The header Content-Security-Policy-Report-Only exists specifically to avoid that: it reports every violation a strict policy would produce, via the report-uri or report-to directive, without blocking anything. Nothing the page actually does changes; you get a log of everything the enforced version would have stopped.

The practical rollout most teams follow is to run report-only against production traffic for a few days, read the violation reports, add the legitimate sources that show up, and only then flip the header to the enforcing Content-Security-Policy. Skipping that step is the single most common reason a CSP rollout gets reverted a week after launch.

Before it goes anywhere near report-uri tracking, a policy is worth reading the way this article just walked through one: directive by directive, checking that script-srcdoesn't quietly include 'unsafe-inline' next to a nonce (which defeats the nonce, since browsers that support nonces ignore 'unsafe-inline' only when a nonce or hash is present — older browsers honor both), that default-src isn't missing entirely, and that a wildcard like https: hasn't been used as a shortcut that allows scripts from any HTTPS host. GenKitLab's HTTP Header Analyzer does this reading for you: paste response headers copied from curl or DevTools and it explains each one, flags missing security headers, calls out specific CSP weaknesses like an open script-src or a nonce sitting next to 'unsafe-inline', and checks cookie flags and cache header contradictions in the same pass — a broader security headers review than a CSP checker alone. It runs entirely client-side; the headers you paste are never uploaded anywhere. If the policy in question is protecting a page that also issues auth tokens, the JWT Decoder is the companion check — CSP stops a stolen token from being read by injected script in the first place, but decoding the token itself is a separate question worth its own tool.