Content Security Policy (CSP) Checker
Analyze the Content-Security-Policy header on any URL or validate your CSP by pasting raw headers. This tool identifies dangerous directives like unsafe-eval, overly broad wildcards, and missing protections like object-src 'none'.
What is Content-Security-Policy?
Content Security Policy (CSP) is an HTTP response header that allows website operators to control which resources the browser is allowed to load. It is the most powerful defense against Cross-Site Scripting (XSS) attacks. A properly configured CSP creates a whitelist of trusted content sources — blocking injected scripts, malicious iframes, and unauthorized resource loading even if an attacker successfully injects code into your HTML.
Why It Matters
XSS is consistently the most common critical vulnerability in web applications. A robust CSP can prevent even successful XSS injections from causing harm by blocking script execution. For sites handling financial data, healthcare records, or personal information, CSP is not optional — it is a baseline security requirement. PCI-DSS 4.0 now explicitly requires CSP for payment pages.
Common Configuration Mistakes
- ✗Using 'unsafe-inline' in script-src without nonce or hash-based exceptions
- ✗Using 'unsafe-eval' which allows eval() and is exploitable via prototype pollution
- ✗Deploying CSP directly in enforcement mode without testing Report-Only first
- ✗Omitting object-src — allows Flash/plugin-based attacks in older browsers
- ✗Omitting base-uri — allows base tag injection to hijack relative URL resolution
- ✗Using overly broad wildcards like *.googleapis.com without path restrictions
- ✗Forgetting frame-ancestors, leaving the site vulnerable to clickjacking
- ✗Not including upgrade-insecure-requests on HTTPS sites
Recommended Configuration
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests;
Frequently Asked Questions
What is the difference between CSP and X-Frame-Options?
X-Frame-Options controls only iframe embedding (clickjacking protection). CSP's frame-ancestors directive does the same but also controls nested contexts. CSP is far more powerful — it covers scripts, styles, images, connections, and more.
Why does my CSP with 'unsafe-inline' still allow XSS?
Exactly right — it does. 'unsafe-inline' negates most XSS protection provided by script-src. The only safe way to allow inline scripts is using nonces (CSP3) or SHA hashes, which tie allowed scripts to specific code.
How do I implement CSP without breaking my site?
Start with Content-Security-Policy-Report-Only header pointing to a report endpoint (or use report-uri.com). Deploy and monitor violations for 1-2 weeks. Then convert to enforcement mode, whitelisting sources that caused legitimate violations.
Does CSP protect against all XSS?
No. CSP is a defense-in-depth measure, not a complete XSS prevention solution. DOM-based XSS can bypass CSP in some configurations. Always combine CSP with input validation, output encoding, and prepared statements.
What CSP level should I target?
Aim for CSP Level 3 with nonce-based or hash-based script allowances. This provides the strongest protection while remaining maintainable. Avoid Level 1-style whitelist-based policies — attackers can bypass them using trusted CDN hosts.
Related Tools & Guides
Need Professional Web Application Security Testing?
This scanner checks visible headers. VAPT Experts provides professional web application penetration testing, API security testing, and compliance-ready security reports.
Request VAPT Assessment