Content Security Policy (CSP) Analysis
Content-Security-Policy is an HTTP header that tells the browser which sources of content are allowed to load. A well-configured CSP is one of the strongest defenses against XSS. A misconfigured one gives a false sense of security while leaving the door wide open.
Try it now
CSP Analyzer
Runs in your browser, nothing leaves your device.
script-src controls where JavaScript can load from. If it includes 'unsafe-inline' or 'unsafe-eval', the CSP provides almost no XSS protection. default-src is the fallback for any directive not explicitly set. object-src should be 'none' to block Flash and Java plugins. base-uri should be restricted to prevent base tag injection that redirects all relative URLs.
Wildcard sources (*.example.com) are too broad if any subdomain can be compromised. Using 'self' seems safe but allows XSS if the attacker can upload files to your origin. CDN allowlisting (e.g., *.cloudflare.com) lets attackers host payloads on the same CDN. The safest approach is nonce-based CSP with strict-dynamic.
Examples
Weak CSP (effectively useless)
script-src 'self' 'unsafe-inline' 'unsafe-eval'
Grade: F. unsafe-inline allows any inline script. unsafe-eval allows eval().
Strong CSP with nonces
script-src 'nonce-abc123' 'strict-dynamic'; object-src 'none'; base-uri 'self'
Grade: A. Only scripts with the correct nonce execute.
Security context
CSP is defense in depth. Even if your application has an XSS vulnerability, a strict CSP prevents the attacker's payload from executing. But a permissive CSP with unsafe-inline is security theater.
Frequently asked
unsafe-inline allows any inline JavaScript (<script> tags, onclick handlers, javascript: URLs) to execute. This completely defeats the purpose of CSP for XSS prevention, since most XSS attacks inject inline scripts.
Start with Content-Security-Policy-Report-Only to log violations without blocking. Fix the violations by moving inline scripts to external files, replacing inline event handlers with addEventListener, and using nonces or hashes for scripts that must be inline.
Related techniques
CORS Misconfigurations and Security Risks
Detect dangerous CORS configurations: wildcard origins with credentials, reflected origins, null origin attacks, and overly permissive access-control headers.
Cookie Security Flags: Secure, HttpOnly, SameSite
Audit cookie security attributes. Detect session cookies missing Secure, HttpOnly, or SameSite flags that enable session hijacking and CSRF attacks.
HTTP Security Headers Checklist
Review HTTP response headers for security misconfigurations. Check for missing HSTS, X-Content-Type-Options, X-Frame-Options, and information leaks in Server headers.