How Content-Security-Policy works
A policy is a list of directives separated by semicolons. Each lists allowed sources; anything else is blocked and reported in the console. A strict policy uses nonces or hashes for scripts instead of allowing domains. Roll a new policy out with Content-Security-Policy-Report-Only first, which reports violations without blocking.
Directives
| Value | Meaning |
|---|---|
default-src 'self'
|
Fallback for every fetch directive that isn’t set. |
script-src 'nonce-r4nd0m' 'strict-dynamic'
|
Only scripts carrying this nonce (and what they load) may run. |
style-src 'self' 'unsafe-inline'
|
Styles from your origin, plus inline styles. |
img-src * data:
|
Images from anywhere, including data: URLs. |
connect-src 'self' https://api.example.com
|
Where fetch, XHR and WebSockets may connect. |
frame-ancestors 'none'
|
Who may embed this page in a frame. Replaces X-Frame-Options. |
upgrade-insecure-requests
|
Load http:// subresources over https:// instead. |
report-to csp-endpoint
|
Send violation reports to an endpoint defined in Reporting-Endpoints. |
Examples
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'; frame-ancestors 'none'
Content-Security-Policy: script-src 'nonce-4AEemGb0xJptoIGFP3Nd' 'strict-dynamic'; object-src 'none'; base-uri 'none'
Common mistakes
-
'unsafe-inline'in script-src undoes most of the XSS protection; use nonces or hashes instead. -
A
<meta http-equiv="Content-Security-Policy">tag works for most directives, but not frame-ancestors, report-to or sandbox.
Check it
curl -sI https://example.com | grep -i '^content-security-policy:'
Paste a full set of response headers into the HTTP header checker to get every header explained and common mistakes flagged.
Related headers
- X-Frame-Options: controls whether the page may be shown in a frame on another site, to prevent clickjacking.
- Strict-Transport-Security: tells browsers to use only HTTPS for this site, for a given time (HSTS).
- X-Content-Type-Options: stops browsers from guessing (“sniffing”) a response’s type instead of trusting Content-Type.
More security headers
Referrer-Policy , Permissions-Policy , Cross-Origin-Opener-Policy , Cross-Origin-Embedder-Policy , Cross-Origin-Resource-Policy .
Sources
Spotted a mistake? Email hello@devtoolsmith.com and we’ll fix it.
Frequently asked questions
What does the Content-Security-Policy header do?
The Content-Security-Policy response header restricts where a page may load scripts, styles, images and other resources from, to contain XSS. A policy is a list of directives separated by semicolons. Each lists allowed sources; anything else is blocked and reported in the console. A strict policy uses nonces or hashes for scripts instead of allowing domains. Roll a new policy out with Content-Security-Policy-Report-Only first, which reports violations without blocking.
How do I see the Content-Security-Policy header?
Run "curl -sI https://example.com" to print a response’s headers, or open the Network tab in your browser’s dev tools and select the request. Paste the headers into the HTTP header checker on this site to get each one explained.