CSP

CSP (Content Security Policy) is an HTTP response header that tells browsers which sources of content the page trusts. Defines whitelists per content type: script-src for JavaScript, style-src for CSS, img-src for images, connect-src for fetch/XHR/WebSocket, frame-src for iframes, etc.

Example header: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

CSP’s primary value: defence-in-depth against XSS. Even if an attacker injects JavaScript into your page, a strict CSP prevents the browser from executing it (because it’s loaded from an origin not on the whitelist) or sending data anywhere (because connect-src blocks exfiltration to attacker domains).

Modern best practice: use a nonce-based CSP — each page response includes a random nonce in its CSP header (e.g., script-src 'nonce-AbC123') and inline script tags that match that nonce can run. This is strict but lets you ship dynamic content securely. Static analyzers like Google’s CSP Evaluator score your policy and flag weaknesses.

Common CSP mistakes that defeat the point: using 'unsafe-inline' in script-src (re-allows the inline injection you were trying to block), wildcarding https: as a script source (any HTTPS host can now serve JS to your origin), or trusting a JSONP-capable CDN host that lets attackers craft a URL returning attacker-controlled JavaScript. The 2016 paper “CSP Is Dead, Long Live CSP!” by Google’s security team showed that 95% of policies in the wild were trivially bypassable for exactly these reasons; 'strict-dynamic' + nonces was their proposed fix and is now the default recommendation.

CSP reports policy violations to a URL specified in report-uri (deprecated) or report-to. Deploy a new policy in Content-Security-Policy-Report-Only mode first — the browser will report violations without blocking content, letting you fix legitimate sources before enforcement. Related: XSS, CORS, SRI (Subresource Integrity). Reference: W3C CSP Level 3.

A measured example: how strict-dynamic works

A real-world strict policy looks like: Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. The server generates a fresh 128-bit nonce per response (typically 22 base64url characters), embeds it in matching <script nonce="r4nd0m"> tags, and emits the header. strict-dynamic propagates trust transitively: scripts loaded by the nonced script can themselves load further scripts without explicit whitelisting, but injected unnonced scripts in the page source are blocked. Google’s CSP Evaluator ranks policies on a 0-10 scale; a strict-dynamic policy with no 'unsafe-inline' and no host wildcards scores 9+, whereas a typical legacy policy with wildcarded CDN sources scores 1-3. The same Google study covering 1.6 million policies across the Alexa top million found that adding strict-dynamic cut the XSS-bypassable share from 95% to under 5%.

How CSP interacts with browser features

CSP blocks more than just script execution. connect-src restricts fetch, XHR, WebSocket, EventSource, and the Beacon API — useful for stopping data exfiltration even after a successful XSS. frame-ancestors replaces the older X-Frame-Options header for clickjacking protection. upgrade-insecure-requests automatically rewrites HTTP subresource URLs to HTTPS. require-trusted-types-for 'script' opts the page into the Trusted Types API, which forces all DOM sinks (innerHTML, eval, etc.) to accept only specially-typed objects, blocking DOM-based XSS at the source. Modern browsers send violation reports as JSON to the report-to endpoint, batched via the Reporting API. Reference: Google’s “CSP Is Dead, Long Live CSP!” ACM CCS 2016 paper.