Content Security Policy (CSP)
What is Content Security Policy (CSP)?
Content Security Policy (CSP)An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
Content Security Policy is delivered via the Content-Security-Policy response header (or a meta element) and enforces a fine-grained allow-list per resource type: script-src, style-src, img-src, connect-src, frame-ancestors and more. It is standardised by the W3C, with CSP Level 3 introducing the primitives that make strict policies practical. A defence-in-depth control, it significantly reduces the impact of XSS, clickjacking (via frame-ancestors) and mixed content, but does not replace input validation and output encoding.
Host allow-lists are the classic mistake. Google's research (the paper CSP Is Dead, Long Live CSP!, analysing ~1 billion pages) found that the vast majority of host-based policies were trivially bypassable — typically because a whitelisted CDN also served JSONP endpoints or an outdated Angular/AngularJS build usable as a gadget. The modern answer is a strict, nonce-based CSP: each response emits a fresh random nonce (script-src 'nonce-r4nd0m'), inline scripts carry that nonce, and injected <script> without it simply does not execute. Pairing the nonce with 'strict-dynamic' lets trusted scripts load their own dependencies while ignoring host allow-lists entirely, which keeps the policy short and CDN-agnostic. Always add object-src 'none' and base-uri 'none' to close <object> and <base>-tag bypasses.
Roll out safely with Content-Security-Policy-Report-Only, which enforces nothing but sends JSON violation reports via report-to/report-uri, so you can tune the policy against real traffic before switching to enforcement. GitHub, Google, and Dropbox all run strict nonce-based CSPs in production. Remember the header is browser-enforced client-side, so it mitigates rather than prevents server-side injection.
flowchart TD
A[Server generates response] --> B[Fresh random nonce per request]
B --> C["Header: script-src 'nonce-abc123' 'strict-dynamic'; object-src 'none'; base-uri 'none'"]
C --> D[Browser parses page]
D --> E{Script has matching nonce?}
E -->|Yes: legitimate inline script| F[Execute + strict-dynamic loads its deps]
E -->|No: XSS-injected script tag| G[Blocked]
G --> H[Violation report to report-to endpoint]
style F fill:#27ae60,color:#fff
style G fill:#c0392b,color:#fff● Examples
- 01
Header: 'Content-Security-Policy: script-src 'self' 'nonce-r4nd0m'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'.
- 02
Reporting policy: 'Content-Security-Policy-Report-Only' used to test a stricter CSP before enforcing it.
● Frequently asked questions
What is Content Security Policy (CSP)?
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks. It belongs to the Application Security category of cybersecurity.
What does Content Security Policy (CSP) mean?
An HTTP response header that tells the browser which sources of scripts, styles, frames and other content are allowed, limiting the impact of XSS and data-injection attacks.
How do you defend against Content Security Policy (CSP)?
Defences for Content Security Policy (CSP) typically combine technical controls and operational practices, as detailed in the full definition above.
What are other names for Content Security Policy (CSP)?
Common alternative names include: CSP.