How to add a Content-Security-Policy
A CSP tells browsers which scripts, styles and frames may load, and blocks most cross-site scripting even when a plugin has a hole.
Step by step, with screenshots: Console errors and deprecated APIs: what the report flags →
Check your own site
Runs these 2 checks and the other 185, free, in about 45 seconds.
What a passing site looks like
- Content-Security-Policy header is setwarning · −6 ptseffort M
- Content-Security-Policy blocks inline and wildcard scriptswarning · −2 ptseffort M
1. Content-Security-Policy header is missing
Why it matters. A CSP blocks most cross-site scripting attacks by listing where scripts may load from. Without one, a single injected script can steal sessions or card data.
- Start in report-only mode with Content-Security-Policy-Report-Only to see what would break.
- Move to an enforcing policy once the report is quiet; keep "unsafe-inline" out of script-src.
In a report the technical detail reads: Response headers contained neither content-security-policy nor content-security-policy-report-only.
2. Content-Security-Policy still allows inline or wildcard scripts
Why it matters. A script-src with 'unsafe-inline', 'unsafe-eval' or a * source still lets an injected script run, so the policy gives little of the protection you set it up for.
- Move inline scripts into files and allow them by nonce or hash instead of 'unsafe-inline'.
- Replace * with the exact origins your scripts load from; drop 'unsafe-eval' once no library needs it.