Content Security Policy

Content Security Policy is an HTTP response header that restricts which scripts, styles, frames, and connections a page may load, reducing the impact of cross-site scripting.

security

Definition

Content Security Policy is a browser-enforced allowlist delivered through an HTTP response header or meta element. It declares trusted sources for scripts, styles, images, frames, and network connections, and can require nonces or hashes for inline code, limiting what injected content can execute.

Context and scope

CSP is a defense-in-depth control for every application that renders HTML, especially those handling user-generated content or loading third-party scripts. It complements output encoding and input validation rather than replacing them.

Common misconceptions

Adding a CSP removes the need to encode or sanitize untrusted output
Any policy containing unsafe-inline still provides strong script protection

Anti-patterns

Shipping default-src * to make a broken page load instead of fixing the policy
Deploying a strict policy for the first time without report-only monitoring

Related concepts

Related examples

Authoritative source

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

How CSP works

A policy is a list of directives such as default-src, script-src, style-src, img-src, and connect-src. Each directive lists allowed sources; default-src is the fallback. A nonce or hash permits specific inline scripts without opening the door to all inline code. frame-ancestors controls who may embed the page, while report-uri or report-to collects violations. Content-Security-Policy-Report-Only observes without blocking.

When to use it

Deploy CSP on every application that renders HTML, particularly pages that display user-generated content or load third-party scripts. Start in report-only mode, collect violations, remove inline handlers and eval, then enforce. A strict policy is strong defense in depth against XSS, but it does not fix server-side injection, misconfigured authorization, or a compromised dependency that is explicitly allowed.

Trade-offs

Strict policies break inline event handlers, bookmarklets, some analytics snippets, and older libraries, which raises migration cost. unsafe-inline is ignored when a nonce or hash is present in modern browsers, but legacy behavior varies. Reporting endpoints can leak URLs and must be protected. Policies also grow complex and drift as teams add vendors, so review them like code.

Example

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-r4nd0m'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

Generate a fresh nonce per response and set the same value on each allowed script tag. Avoid unsafe-eval, and host third-party scripts on origins you control when possible.

CSP is not a substitute for output encoding: injected HTML can still deface a page or exfiltrate data through allowed channels. frame-ancestors controls embedding of your page, not which frames your page may load. Related concepts include XSS, CORS, and supply chain security.