Strict CSP Policy Example
Build a strict Content Security Policy that maximizes XSS protection. Learn the nonce-based strict policy recommended by Google, with default-src 'none' and strict-dynamic.
Detailed Explanation
Building a Strict CSP
A strict CSP minimizes the attack surface by defaulting to blocking everything and only allowing explicitly trusted resources. Google's web security team recommends a nonce-based strict policy as the gold standard.
Google's Recommended Strict Policy
Content-Security-Policy:
script-src 'nonce-{random}' 'strict-dynamic';
object-src 'none';
base-uri 'self';
This three-directive policy provides strong XSS protection because:
- Scripts only execute with a valid nonce
'strict-dynamic'allows trusted scripts to load dependenciesobject-src 'none'blocks Flash and other plugin-based attacksbase-uri 'self'prevents base tag hijacking
Full Strict Policy Example
Content-Security-Policy:
default-src 'none';
script-src 'nonce-abc123' 'strict-dynamic';
style-src 'nonce-abc123';
img-src 'self' data:;
font-src 'self';
connect-src 'self' https://api.example.com;
frame-src 'none';
object-src 'none';
base-uri 'self';
form-action 'self';
frame-ancestors 'none';
upgrade-insecure-requests;
report-uri /csp-report
Why default-src 'none'?
Starting with default-src 'none' ensures that any resource type you forget to configure is blocked by default. This is the principle of least privilege applied to CSP:
- If you forget to add
media-src, audio and video are blocked (safe default) - If you forget to add
font-src, custom fonts are blocked (minor visual impact, but secure) - If you forget to add
frame-src, iframes are blocked (prevents clickjacking)
Strict Policy vs Allowlist Policy
Allowlist-based (legacy):
script-src 'self' https://cdn.example.com https://analytics.example.com
Research by Google has shown that host-based allowlists are often bypassable because:
- CDNs host millions of scripts, including exploitable ones
- JSONP endpoints can be abused to execute arbitrary code
- Angular/jQuery on CDNs can be used for CSP bypasses
Nonce-based strict:
script-src 'nonce-abc123' 'strict-dynamic'
This is immune to the above bypasses because only scripts with the correct nonce execute, regardless of their origin.
Migration Path
- Deploy
Content-Security-Policy-Report-Onlywith the strict policy - Add nonces to all legitimate inline scripts
- Monitor violation reports for 2-4 weeks
- Fix all legitimate violations
- Switch to enforced
Content-Security-Policy - Keep report-uri active for ongoing monitoring
Use Case
A strict CSP is recommended for any application handling sensitive data: banking sites, healthcare portals, SaaS platforms, and government services. Even content-focused sites benefit from strict CSP to prevent SEO spam injection and ad fraud. The nonce-based strict approach is now considered industry best practice and is recommended by OWASP, Google, and Mozilla.