Common CSP Implementation Mistakes
Content Security Policy is powerful but easy to misconfigure. Here are the top mistakes we see when scanning websites.
1. Using unsafe-inline
Problem: Allows any inline script to run, defeating XSS protection.
Fix: Use nonces or hashes instead.
2. Using unsafe-eval
Problem: Allows eval() and similar functions that can execute strings as code.
Fix: Refactor code to avoid eval(), new Function(), and setTimeout with strings.
3. Wildcard Sources (*)
Problem: script-src * allows scripts from any domain.
Fix: Whitelist only specific trusted domains.
4. Missing default-src
Problem: Without default-src, undefined directives have no restrictions.
Fix: Always set default-src 'none' or default-src 'self' as a baseline.
5. Forgetting object-src
Problem: Plugins like Flash can be exploited if not restricted.
Fix: Set object-src 'none' unless you specifically need plugins.
6. Overly Permissive CDN Whitelisting
Problem: Whitelisting CDNs like jsdelivr.net allows attackers to serve malicious code from those CDNs.
Fix: Use strict-dynamic with nonces, or use subresource integrity (SRI).
7. Not Using Report-Only First
Problem: Deploying CSP directly to production can break your site.
Fix: Start with Content-Security-Policy-Report-Only to test.
8. Ignoring CSP Reports
Problem: Not monitoring violations means you miss attacks and misconfigurations.
Fix: Set up report-uri or report-to and monitor regularly.
9. Data: URI in script-src
Problem: data: URIs can embed malicious scripts.
Fix: Remove data: from script-src.
10. CSP in Meta Tag Only
Problem: Meta tag CSP cannot use report-uri and some directives.
Fix: Use HTTP headers as the primary CSP delivery method.
Check Your CSP
Use our free analyzer to identify these and other issues in your CSP implementation.