Want to learn more?
Learn how to create and deploy Content Security Policy headers to prevent XSS and data injection.
Read the guideCSP Breaking Your Site?
Our DevSecOps team implements Content Security Policies that protect without disrupting functionality.
What Is Content Security Policy (CSP)
Content Security Policy (CSP) is an HTTP security header that controls which resources a browser is allowed to load and execute on a web page. By defining a whitelist of trusted content sources, CSP prevents Cross-Site Scripting (XSS), data injection attacks, clickjacking, and other code injection vulnerabilities. It is one of the most effective client-side security controls available and is recommended by OWASP, NIST, and every major web security standard.
XSS remains the most common web vulnerability, affecting approximately 65% of web applications. CSP provides defense-in-depth against XSS by ensuring that even if an attacker injects malicious HTML, the browser refuses to execute unauthorized scripts, load unauthorized resources, or submit data to unauthorized endpoints.
How CSP Works
CSP is delivered as an HTTP response header that specifies directives controlling different resource types:
| Directive | Controls | Example |
|---|---|---|
| default-src | Fallback for all resource types | default-src 'self' |
| script-src | JavaScript sources | script-src 'self' cdn.example.com |
| style-src | CSS stylesheets | style-src 'self' 'unsafe-inline' |
| img-src | Image sources | img-src 'self' data: images.example.com |
| font-src | Web fonts | font-src 'self' fonts.googleapis.com |
| connect-src | AJAX, WebSocket, fetch targets | connect-src 'self' api.example.com |
| frame-src | Iframe sources | frame-src 'none' |
| object-src | Plugins (Flash, Java) | object-src 'none' |
| base-uri | Allowed | base-uri 'self' |
| form-action | Form submission targets | form-action 'self' |
| frame-ancestors | Who can embed this page | frame-ancestors 'none' |
| report-uri / report-to | Where to send violation reports | report-to csp-reports |
Source values:
'self'— Same origin only'none'— Block all resources of this type'unsafe-inline'— Allow inline scripts/styles (weakens CSP significantly)'unsafe-eval'— Allow eval() and similar (weakens CSP significantly)'nonce-{random}'— Allow specific inline scripts with a matching nonce'strict-dynamic'— Trust scripts loaded by already-trusted scripts- Domain names — Explicit origin allowlisting
Common Use Cases
- XSS mitigation: Prevent injected scripts from executing by restricting script sources
- Data exfiltration prevention: Restrict connect-src to prevent stolen data from being sent to attacker servers
- Clickjacking defense: Use frame-ancestors to prevent your site from being embedded in malicious iframes
- Mixed content prevention: Enforce HTTPS-only resources with upgrade-insecure-requests
- Third-party script control: Explicitly allow only approved third-party scripts (analytics, chat, ads)
Best Practices
- Start with Content-Security-Policy-Report-Only — Deploy in report-only mode first to identify violations without breaking functionality
- Never use unsafe-inline for scripts — Use nonces or hashes instead; unsafe-inline defeats the purpose of CSP for XSS prevention
- Set object-src to none — Plugins are legacy technology and a common attack vector; block them entirely
- Use nonce-based CSP for modern apps — Generate a unique nonce per request and add it to allowed inline scripts:
script-src 'nonce-abc123' - Monitor violation reports — CSP reporting reveals both attacks and legitimate resources you forgot to whitelist
References & Citations
- World Wide Web Consortium (W3C). (2024). Content Security Policy Level 3. Retrieved from https://www.w3.org/TR/CSP3/ (accessed January 2025)
- Mozilla Developer Network. (2024). Content Security Policy (CSP). Retrieved from https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP (accessed January 2025)
- Google. (2024). CSP Evaluator. Retrieved from https://csp-evaluator.withgoogle.com/ (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Frequently Asked Questions
Common questions about the CSP Generator
Content Security Policy (CSP) is HTTP response header that controls resources browsers can load. Prevents XSS, clickjacking, code injection by whitelisting trusted sources. Example: Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com. Directives: script-src (JavaScript), style-src (CSS), img-src (images), connect-src (AJAX/WebSocket). Modern browsers support CSP Level 3. Essential defense layer for web security.
Add CSP header to HTTP responses. Methods: web server config (Nginx, Apache), meta tag in HTML head (limited features), application framework middleware, CDN/WAF rules. Example Nginx: add_header Content-Security-Policy "default-src 'self'"; Start with Content-Security-Policy-Report-Only to test without blocking. Monitor CSP violation reports. Gradually tighten policy. Remove inline scripts/styles or use nonces. Deploy in production when violations resolved.
Nonce (number used once) is cryptographic random value allowing specific inline scripts/styles. Add nonce='random123' to CSP header and matching nonce="random123" to script/style tags. Browser compares nonces. Prevents XSS - attacker cannot guess nonce. Generate new nonce per page load using CSPRNG. Example: script-src 'nonce-4AEemGb0xJptoIGFP3Nd'. Alternative to unsafe-inline. Requires server-side rendering. More secure than hashes for dynamic content.
Key directives: default-src (fallback for all), script-src (JavaScript sources), style-src (CSS), img-src (images), font-src (web fonts), connect-src (fetch/XHR/WebSocket), frame-src (iframes), media-src (video/audio), object-src (plugins), base-uri (base tag), form-action (form submissions). Values: 'self' (same origin), 'none' (block all), https: (any HTTPS), specific domains. Use default-src as baseline, override with specific directives.
Three methods: 1) Nonces - unique token per page load (most secure). 2) Hashes - SHA-256/384/512 hash of script content (for static scripts). 3) unsafe-inline (insecure, avoid). Example with hash: script-src 'sha256-abc123...'. Generate hash: echo -n "alert('hello')" | openssl dgst -sha256 -binary | openssl base64. Best practice: move inline scripts to external files, use nonces for necessary inline code. Avoid unsafe-inline - negates XSS protection.
Content-Security-Policy-Report-Only header tests CSP without blocking resources. Browsers log violations but do not enforce policy. Use to: test new CSP before deployment, identify resources needing whitelisting, monitor for policy violations. Reports sent to report-uri or report-to endpoints. Example: Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report. Deploy report-only first, fix violations, then enforce with Content-Security-Policy header.
Whitelist trusted third-party domains explicitly. Example: script-src 'self' https://cdn.jquery.com https://www.google-analytics.com. Challenges: CDNs (use SRI hashes), ads (relaxed policies needed), social widgets (frame-src), analytics (connect-src). Solutions: host resources locally, use SRI for CDN files, frame third-party content (iframe sandbox), proxy external resources. Balance security vs functionality. Review third-party integrations quarterly. Remove unused scripts.
SRI validates that CDN-hosted files have not been tampered with. Add integrity attribute with cryptographic hash to script/link tags. Example: <script src="https://cdn.example.com/lib.js" integrity="sha384-..." crossorigin="anonymous">. Browser verifies hash before executing. Prevents supply chain attacks (compromised CDN). Generate hashes: openssl dgst -sha384 -binary file.js | openssl base64. Use with CSP for defense in depth. Update hashes when upgrading libraries.