How to implement CSP on my website?

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.

What is CSP nonce and how to use it?

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.

What are common CSP directives?

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.

How to allow inline scripts with CSP?

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.

What is CSP report-only mode?

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.

How to handle CSP for third-party resources?

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.

What is Subresource Integrity (SRI)?

SRI validates that CDN-hosted files have not been tampered with. Add integrity attribute with cryptographic hash to script/link tags. Example: ` `. 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.

Home/Tools/Security/CSP Generator

CSP Generator

Generate Content Security Policy headers to protect your website from XSS attacks and code injection

100% Private - Runs Entirely in Your Browser

No data is sent to any server. All processing happens locally on your device.

Loading CSP Generator...

Builder Tab

Output Format

Report-Only Mode

Loading interactive tool...

JavaScript Required

This interactive tool requires JavaScript to function. Please enable JavaScript in your browser to use the full features.

The tool description and documentation above provide information about this tool's capabilities. For the best experience, please enable JavaScript and refresh the page.

Need Professional Security Testing?

Our penetration testers find vulnerabilities before attackers do. Get a comprehensive security assessment.

Learn About Penetration Testing Explore Risk Assessment

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 tag URLs	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.