What Is Content Security Policy?

Content Security Policy Explainer

Content Security Policy, or CSP, is a browser security mechanism that lets a website declare which content sources and page behaviors are allowed. The policy normally arrives in an HTTP response header, although some rules can be delivered through a meta element. A browser compares scripts, styles, images, frames, connections, fonts, and other resources with the policy before loading or executing them. CSP is especially valuable as a defense-in-depth measure against cross-site scripting, where attacker-controlled text is mistakenly interpreted as active code.

A policy is a list of directives. Each directive governs a resource category or behavior. For example, `script-src` controls script execution, `img-src` controls images, `connect-src` limits destinations used by fetches and similar connections, and `frame-ancestors` specifies which sites may embed the page. Source expressions can name origins, schemes, nonces, or cryptographic hashes. A `default-src` directive supplies a fallback for many categories that do not have a more specific rule. The browser applies each effective directive independently rather than treating the policy as one broad allowlist.

Inline scripts are a common challenge. Allowing every inline script with a broad keyword weakens protection because injected markup can execute in the same way as legitimate inline code. A server can instead create a fresh unpredictable nonce for a response, place it in the policy, and attach it only to approved script elements. The browser runs scripts with the matching nonce and rejects other inline scripts. Hash sources can authorize specific unchanging script contents. Both approaches require the application to keep attacker-controlled values out of authorized blocks.

CSP can also constrain trust as scripts create other scripts. Strict policies often combine nonces or hashes with rules that let a trusted bootstrap script load its necessary dependencies without maintaining a long host list. Other directives can prohibit risky plugin content, force form submissions toward approved destinations, or upgrade eligible insecure requests. Policies should be tailored to the application: a news page, an analytics dashboard, and a payment form may need different connections and embedding rules. A permissive wildcard policy may produce few errors but little meaningful containment.

Deployment commonly begins with report-only mode. The browser evaluates the proposed rules and reports violations without blocking content, allowing operators to find legitimate dependencies and unexpected injections. Reports are signals, not proof of an attack; browser extensions, stale pages, and malformed requests can create noise. After analysis, the site enforces the policy and continues monitoring. Multiple policies become cumulative restrictions, so a resource must satisfy all applicable enforced policies. A later policy cannot simply loosen an earlier one.

CSP does not sanitize unsafe HTML, fix authorization mistakes, or make vulnerable JavaScript correct. Browser support and directive behavior vary, and a policy can be bypassed if it trusts an origin that serves attacker-controlled executable content. Nonces must be generated securely for every response and must not be reused as permanent tokens. Developers also need tests because a small policy change can break application features. The most reliable approach starts with secure output encoding and safe DOM APIs, then adds a narrowly scoped CSP that is tested, monitored, and revised deliberately. CSP’s practical value is containment: even when untrusted content reaches a page, the browser has an independent set of instructions that can stop unexpected scripts, connections, framing, and other dangerous behavior.

Policy inheritance and navigation deserve attention. A framed document enforces its own response policy, while the parent’s framing rules decide whether embedding is allowed. Redirect chains and worker scripts can introduce sources that are easy to miss during testing. Development and production hosts may also require different endpoints, but broad temporary allowances have a habit of becoming permanent. Teams often generate policies from a reviewed application configuration, test them in automated browsers, and examine reports by release version. That makes CSP a maintained security control rather than a header copied once and forgotten.