Deep CSP & Header Report
Enter a URL for a deep, browser-rendered audit of your Content-Security-Policy and security headers. Unlike a plain header dump, this report loads the page in a real (headless) browser so it sees the policy that actually applies after meta tags, redirects and framework defaults — then grades it and gives you exact directive-level fixes. It complements the Web Server Audit (which runs in-process for the fast baseline grade, HSTS-preload eligibility, security.txt, stack fingerprint and cookie flags); use this when you need the deep CSP verdict.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- The effective Content-Security-Policy as a real browser applies it (header + meta)
- An overall letter grade for the security-header posture
- Each weak or missing directive (default-src, script-src, object-src, frame-ancestors, base-uri, …)
- Unsafe CSP values (unsafe-inline, unsafe-eval, wildcard sources)
- Concrete, copy-paste recommendations to harden the policy
How to read the result
- The letter grade summarises overall header posture — aim for A.
- Each issue names the directive at fault and why it weakens the policy.
- unsafe-inline / unsafe-eval / wildcards defeat much of CSP's XSS protection — remove them.
- Apply the listed recommendations, then re-run to confirm the grade improves.
Frequently asked questions
How is this different from the Web Server Audit?
The Web Server Audit runs in-process for a fast baseline: it grades the six key headers A–F, checks HSTS-preload eligibility and security.txt, fingerprints the stack and audits cookie flags. This report goes deeper on CSP specifically — it renders the page in a real browser to evaluate the effective policy and returns directive-level fixes. Use the scanner for the quick all-round check and this for a thorough CSP review.
Why render the page in a browser?
A CSP can be set by an HTTP header, a <meta> tag, or both, and frameworks often inject their own. Reading the raw header alone can miss or misread the policy that actually applies. Rendering the page captures the effective policy the browser enforces.
What makes a CSP weak?
'unsafe-inline' and 'unsafe-eval' let injected scripts run, wildcard sources (*) allow content from anywhere, and a missing object-src/base-uri/frame-ancestors leaves common bypasses open. A strong policy is specific about every source and avoids the unsafe keywords.