Loading...
WebShield Audit
Content-Security-Policy (CSP) Checker
Validate your CSP in one scan - catches the mistakes linters miss.
Hands off to the full WebShield scanner, which covers this check alongside every other header, DNS and email auth probe.
A Content-Security-Policy header is only useful if it actually constrains what your browser will execute. Most real-world CSPs drift into permissive territory - a forgotten `unsafe-inline`, a wildcard `*.cloudfront.net` that swallows half the internet, or a missing `frame-ancestors` that leaves the door open for clickjacking. WebShield's CSP checker parses the header straight off your live response, flags every directive that weakens the policy, and hands you a tightened version.
What this tool checks
- Presence of Content-Security-Policy (and Content-Security-Policy-Report-Only)
- Dangerous sources: unsafe-inline, unsafe-eval, data:, blob:
- Wildcard hosts (*.example.com, *) in script-src, style-src, connect-src
- Missing default-src fallback and missing object-src 'none'
- frame-ancestors directive (the modern replacement for X-Frame-Options)
- base-uri and form-action coverage
- Use of nonces or hashes (strict-dynamic)
- Report-to / report-uri endpoints
Why it matters
CSP is the single most effective browser-side mitigation for XSS, data exfiltration and clickjacking. A tight policy downgrades a critical XSS to a noisy console error. A sloppy policy is security theatre - it looks like a header, but every attacker vector you cared about is still wide open.
How WebShield tests this
WebShield fetches your target URL, reads the Content-Security-Policy response header (or the meta equivalent), tokenises each directive, and scores it against the Google CSP Evaluator ruleset plus the OWASP recommendations. The scanner does not execute JavaScript on your page - it inspects headers and reports.
Paste-ready fixes
Nginx
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'nonce-{{RANDOM}}' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';" always;Apache
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-{{RANDOM}}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';"Vercel
{
"headers": [
{
"source": "/(.*)",
"headers": [
{
"key": "Content-Security-Policy",
"value": "default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-{{RANDOM}}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';"
}
]
}
]
}Cloudflare
// Cloudflare Worker / Transform Rule
response.headers.set(
"Content-Security-Policy",
"default-src 'self'; script-src 'self' 'strict-dynamic' 'nonce-{{RANDOM}}'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; form-action 'self';"
);Frequently asked
What is a good starting CSP?
Begin with Content-Security-Policy-Report-Only so violations are logged but nothing is blocked. A sensible baseline is default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';. Add script-src and style-src using nonces or hashes once you know what your pages legitimately load.
Why is 'unsafe-inline' a problem?
'unsafe-inline' lets any inline <script> or onclick= attribute execute - which is exactly what reflected and stored XSS payloads inject. The whole point of CSP is to refuse unauthorised code, and unsafe-inline disables that protection.
Does frame-ancestors replace X-Frame-Options?
Yes, for any browser that supports CSP level 2+. frame-ancestors is strictly more expressive: it allows multiple origins, wildcards per path, and source expressions. Modern guidance is to set frame-ancestors and keep X-Frame-Options: DENY only as a belt-and-braces fallback for legacy proxies.
What is strict-dynamic?
strict-dynamic tells the browser to trust scripts that are loaded by an already-trusted (nonced or hashed) script. This lets you retire host allowlists - which are trivial to bypass - and rely on nonces instead, which is the Google-recommended modern pattern.
Related
Knowledge base
Missing Content Security Policy (CSP)
High severity · Content
Knowledge base
Missing Subresource Integrity (SRI)
Medium severity · Content
Knowledge base
Missing X-Frame-Options
Medium severity · Content
Deep guide
CSP Safe Rollout: Report-Only to Enforce in Six Stages
Deploy a Content-Security-Policy that actually stops XSS - without shipping a broken site.
Deep guide
HSTS: A Complete, Rollback-Safe Setup Guide
The max-age ramp, subdomain audit and preload submission - in the order they won't burn you.
Tool
HSTS Preload Checker
Test HSTS before you preload - because you only get to do it wrong once.
Tool
Cookie Security Checker
Audit every Set-Cookie on the page - the flags that matter, in one scan.
Tool
security.txt Checker
Make it obvious how to report vulnerabilities - the RFC 9116 way.