Security header analyzer for Content-Security-Policy. Paste your CSP and get per-directive risk assessment. 100% client-side.
Content-Security-Policy (CSP) is an HTTP response header that controls which resources a browser is allowed to load for a given page. It is the primary defense against cross-site scripting (XSS), clickjacking, and data injection attacks. A well-configured CSP can prevent attackers from executing malicious scripts even if they find an injection vulnerability.
| Directive | Controls | Common mistake |
|---|---|---|
| default-src | Fallback for all resource types | Setting to * (allows everything) |
| script-src | JavaScript sources | Using unsafe-inline or unsafe-eval |
| style-src | CSS sources | Allowing unsafe-inline broadly |
| img-src | Image sources | Wildcards for data: URIs |
| connect-src | XHR, WebSocket, fetch targets | Missing (falls back to default-src) |
| frame-ancestors | Who can embed this page | Not set (allows clickjacking) |
Start with a report-only policy to identify violations without breaking your site:
Content-Security-Policy-Report-Only:
default-src 'self';
script-src 'self' 'nonce-{random}';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
report-uri /csp-reportOnce violations are resolved, switch from Report-Only to enforcing mode. Use nonce-based or hash-based script loading instead of unsafe-inline for maximum protection.
No. You paste your CSP header value and the analysis runs entirely in your browser. No requests are made to your server or any external service.
Each directive is rated as safe, warning, or critical based on known attack vectors. Critical findings like unsafe-eval in script-src or wildcard default-src indicate XSS risk.
CSP is a strong defense-in-depth layer but not a silver bullet. Combine it with output encoding, input validation, and HTTP-only cookies for comprehensive XSS protection.