Content-Security-Policy
Example Policies
Writing a strong CSP — start with strict-dynamic
Modern CSP best practice (CSP Level 3) uses a nonce-based + strict-dynamic approach — the server generates a random nonce per request, adds it to the CSP header AND every legitimate <script>, and the browser trusts only those scripts and scripts they load.
Content-Security-Policy:
default-src 'self';
script-src 'nonce-{RANDOM}' 'strict-dynamic' https: 'unsafe-inline';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https:;
font-src 'self' https://fonts.gstatic.com;
connect-src 'self' https://api.example.com;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
upgrade-insecure-requests;
report-uri /csp-report;
Why this shape:
'nonce-{RANDOM}'— the server-generated random value matches the nonce attribute on your first-party scripts.'strict-dynamic'— any script loaded by a nonce-allowed script is also trusted (handles module loaders, AMP, etc.).'unsafe-inline'+https:— ignored by browsers that support strict-dynamic; they're fallbacks for older browsers. Backward-compatible, not dangerous on modern browsers.frame-ancestors 'none'— anti-clickjacking. Replaces oldX-Frame-Options: DENY.report-uri— browsers POST violation reports here. Monitor to spot issues early.
Start in report-only mode (Content-Security-Policy-Report-Only) for 1-2 weeks before switching to enforcing mode. Our evaluator simulates violations without you needing to deploy.
Frequently Asked Questions
How do I evaluate a Content Security Policy (CSP) header?
Paste your `Content-Security-Policy` header. The evaluator flags unsafe directives (`unsafe-inline`, `unsafe-eval`, `*` wildcards), missing directives (`default-src`, `script-src`, `object-src`), and suggests secure alternatives (nonces, hashes, strict-dynamic). Modelled after Google's CSP evaluator.
What is CSP and why do I need it?
Content Security Policy is an HTTP header that tells browsers which sources of scripts, styles, images, etc. are allowed. Strong CSP is the main defence against XSS — even if an attacker injects a `<script>` tag, the browser refuses to run it if the source isn't whitelisted.
Is `unsafe-inline` or `unsafe-eval` really unsafe?
Yes. `unsafe-inline` lets inline `<script>` and `style` attrs run — the most common XSS vector. `unsafe-eval` allows `eval()`, `new Function()`, etc. Use nonces or hashes instead for inline scripts, and avoid `eval()` in modern code. Our evaluator grades your CSP and tells you what to replace.
What's the difference between CSP level 1, 2 and 3?
CSP 1 = basic whitelists. CSP 2 = adds nonce/hash, `child-src`, `frame-ancestors`. CSP 3 = adds `strict-dynamic`, `worker-src`, `trusted-types`, report-to. Use `strict-dynamic` with a nonce for the most flexible strong policy — the evaluator suggests this where appropriate.
How do I deploy a CSP in nginx, Apache, ASP.NET or Express?
nginx: `add_header Content-Security-Policy "..." always;`. Apache: `Header set Content-Security-Policy "..."`. ASP.NET: middleware `context.Response.Headers.Add("Content-Security-Policy", "...")`. Express: `helmet.contentSecurityPolicy({ directives: { ... } })`. Test in report-only mode first.
Smarter quality checks. Faster deployments.
Better apps.
