Generate Content Security Policy headers to prevent XSS, clickjacking, code injection. Configure directives visually. Validate CSP syntax and best practices.
Use this free online CSP Generator & Evaluator directly in your browser. No signup required, no data leaves your device. Part of Utilier — a collection of 133+ developer utilities.
What is Content Security Policy (CSP) Generator?
Content Security Policy (CSP) is an HTTP header that prevents cross-site scripting (XSS), clickjacking, and other code injection attacks by controlling which resources (scripts, styles, images, fonts) can load on your web page. This tool generates CSP headers visually — select directives (script-src, style-src, img-src), set allowed sources (self, CDN domains, inline, unsafe-eval), and copy the CSP header for use in your web server or meta tags. Validates syntax and warns about insecure configurations.
Directive configuration: Set allowed sources for each resource type: script-src (JavaScript), style-src (CSS), img-src (images), font-src (fonts), connect-src (fetch/XHR), frame-src (iframes).
XSS protection: Blocks execution of unauthorized scripts. If attacker injects <script src='evil.com/hack.js'>, CSP blocks it (not in script-src). Prevents most XSS attacks.
Reporting: report-uri or report-to directives send violation reports to an endpoint. Monitor CSP violations in production to detect attacks or misconfigurations.
Nonce and hash support: Use nonces (random tokens) or hashes (SHA-256) to allow specific inline scripts/styles without 'unsafe-inline'. More secure than blanket inline permission.
Why use CSP generator?
Writing CSP headers manually is complex — dozens of directives, source syntax, default fallbacks. This tool simplifies CSP creation with visual UI and validation.
Prevent XSS attacks: CSP is the strongest defense against XSS (cross-site scripting). Even if attacker injects malicious code, CSP blocks execution if source is not whitelisted.
Avoid syntax errors: CSP syntax is strict: directives separated by semicolons, sources by spaces, quotes around keywords ('self', 'unsafe-inline'). Typos break the policy. Tool validates syntax.
Learn CSP directives: See how script-src, style-src, img-src, and other directives control resource loading. Experiment with 'self', 'unsafe-inline', nonces, and hashes.
Security best practices: Tool warns about insecure configurations (unsafe-inline, unsafe-eval) and suggests safer alternatives (nonces, hashes, strict-dynamic).
Save time: No need to reference CSP specs for directive names or source syntax. Tool handles formatting and validation automatically.
Test and iterate: Use report-only mode (Content-Security-Policy-Report-Only header) to test CSP without breaking your site. Fix violations, then enforce.
When to use CSP generator
Use whenever you need to secure a web application against XSS and code injection attacks.
Adding CSP to production web apps to prevent XSS attacks from user input (comments, forms, search).
Migrating legacy apps to CSP by starting with report-only mode and fixing violations incrementally.
Blocking unauthorized third-party scripts (ad injectors, malware) from loading on your site.
Preventing clickjacking with frame-ancestors directive (controls who can embed your site in iframes).
Securing single-page apps (React, Vue, Angular) by whitelisting CDN sources and using nonces for inline scripts.
Enforcing HTTPS by using upgrade-insecure-requests directive (upgrades HTTP requests to HTTPS).
Learning CSP by experimenting with directives and testing in browser DevTools console.
How to use CSP generator
Select directives, set allowed sources, generate CSP header.
Set allowed sources: For each directive, specify sources: 'self' (same origin), https://cdn.example.com (specific domain), 'unsafe-inline' (inline scripts/styles), 'unsafe-eval' (eval()), 'none' (block all).
Add nonce or hash (optional): For inline scripts/styles, use nonce-<random> or sha256-<hash> instead of 'unsafe-inline'. More secure. Generate nonce server-side for each page load.
Configure reporting (optional): Set report-uri or report-to to send violation reports to an endpoint. Monitor CSP violations to detect attacks or bugs.
Validate policy: Click Validate to check syntax, detect insecure directives (unsafe-inline, unsafe-eval), and get security recommendations.
Test in report-only mode: Use Content-Security-Policy-Report-Only header to test without breaking your site. Check browser console for violations, fix issues, then switch to enforcing mode.
Copy header: Click Copy to get the CSP header. Add to web server config (Nginx, Apache) or meta tag (<meta http-equiv='Content-Security-Policy' content='...'/>).
Key features
Visual directive builder: Select script-src, style-src, img-src, font-src, connect-src, frame-src, default-src from UI. Set sources per directive.
Source whitelisting: Choose 'self', specific domains (https://cdn.example.com), 'unsafe-inline', 'unsafe-eval', 'none', or custom sources.
Nonce and hash support: Generate nonce-<token> or sha256-<hash> for inline scripts/styles. Safer than 'unsafe-inline'.
Security warnings: Warns about unsafe-inline, unsafe-eval, * (wildcard). Suggests nonces, hashes, or strict-dynamic.
Reporting configuration: Set report-uri or report-to to receive violation reports. Monitor attacks and misconfigurations in production.
Report-only mode: Generate Content-Security-Policy-Report-Only header to test CSP without enforcement. Fix violations before enabling.
Common use cases
XSS prevention: Block unauthorized scripts from executing. Whitelist only trusted sources (self, CDN). Prevents XSS attacks from injected code.
Clickjacking protection: Use frame-ancestors 'self' to prevent your site from being embedded in iframes on other domains. Stops clickjacking attacks.
Third-party script control: Whitelist specific CDNs (https://cdn.jsdelivr.net, https://cdnjs.cloudflare.com). Block unauthorized third-party scripts (malware, ad injectors).
HTTPS enforcement: Use upgrade-insecure-requests to automatically upgrade HTTP requests to HTTPS. Ensures all resources load over secure connection.
Inline script security: Replace 'unsafe-inline' with nonces or hashes for inline scripts. Generate nonce server-side, add to script tag and CSP. More secure than blanket inline permission.
API request control: Use connect-src to whitelist allowed AJAX/fetch endpoints. Block unauthorized API requests to external domains.
Allows same-origin scripts + inline scripts with matching nonce. Use <script nonce='abc123'>...</script>. Generate new nonce per request (server-side).
frame-src: where you can embed iframes. frame-ancestors: who can embed your site. Example: frame-ancestors 'self'; (prevents clickjacking).
default-src
Fallback for all directives. If script-src is not set, default-src applies. Example: default-src 'self'; (allows only same-origin resources).
Nonce
Random token for inline scripts/styles. Example: script-src 'nonce-abc123'; <script nonce='abc123'>...</script>. Generate new nonce for each page load (server-side).
Hash
SHA-256 hash of inline script/style content. Example: script-src 'sha256-xyz...'; <script>alert('hi')</script>. Hash must match script content. Use for static inline code.
Common mistakes to avoid
Using 'unsafe-inline' and 'unsafe-eval' everywhere, defeating CSP's purpose
Why it happens: CSP's main goal is to prevent inline script execution (XSS). 'unsafe-inline' allows all inline scripts/styles, 'unsafe-eval' allows eval(). If attacker injects <script>maliciousCode()</script>, it runs. This negates CSP's XSS protection. Common for developers who want 'quick fix' to CSP violations without refactoring code.
How to avoid it: Remove inline scripts and styles, move to external files. For necessary inline code, use nonces (server-generated tokens) or hashes (SHA-256 of script content). Use strict-dynamic to allow dynamically loaded scripts from trusted sources.
Forgetting quotes around keywords ('self', 'unsafe-inline', 'none'), causing CSP to fail
Why it happens: CSP keywords must be quoted: 'self', 'unsafe-inline', 'none', 'nonce-abc'. Without quotes (self, unsafe-inline), browser treats them as domain names, not keywords. Policy fails silently, resources are blocked. Common typo that breaks CSP.
How to avoid it: Always quote keywords: script-src 'self' 'unsafe-inline'; (correct), not script-src self unsafe-inline; (wrong). Domain names are never quoted: https://cdn.example.com (no quotes).
Not testing CSP in report-only mode first, breaking production site instantly
Why it happens: CSP blocks resources immediately when enforced. If your CSP is too strict (missing CDNs, blocking inline scripts), your site breaks (blank page, missing styles, JS errors). Users see broken UI. Testing in production = downtime.
How to avoid it: Use Content-Security-Policy-Report-Only header first. This reports violations without blocking resources. Monitor violation reports (browser console or report-uri endpoint), fix issues, then switch to enforcing mode (Content-Security-Policy).
Using wildcard sources (script-src https:, script-src *), allowing any HTTPS script
Why it happens: script-src https: or script-src * allows scripts from any HTTPS domain. Attacker can inject <script src='https://evil.com/hack.js'> and CSP allows it. This defeats whitelisting. Common when developers want 'just allow everything' policy.
How to avoid it: Whitelist specific domains: script-src 'self' https://cdn.example.com https://ajax.googleapis.com; Do not use https:, http:, or *. Be explicit about allowed sources.
Why it happens: If you set script-src but not img-src, and no default-src, images may be blocked (no directive = default to 'none'). default-src is the fallback for all resource types. Without it, you must set every directive explicitly (img-src, font-src, connect-src, etc.).
How to avoid it: Set default-src as a baseline: default-src 'self'; Then override specific directives: script-src 'self' https://cdn.example.com; This allows same-origin images, fonts, etc., while customizing scripts.
Frequently asked questions
What is the difference between Content-Security-Policy and Content-Security-Policy-Report-Only?
Content-Security-Policy enforces the policy (blocks violations). Content-Security-Policy-Report-Only reports violations without blocking (testing mode). Use report-only to test CSP on production before enforcing.
What is a nonce and how do I use it?
A nonce is a random token (nonce-abc123) generated server-side for each page load. Add to CSP (script-src 'nonce-abc123') and inline script tag (<script nonce='abc123'>). Only scripts with matching nonce execute. More secure than unsafe-inline.
How do I allow inline styles without unsafe-inline?
Use nonces or hashes. Nonce: style-src 'nonce-xyz'; <style nonce='xyz'>. Hash: calculate SHA-256 of style content, add to CSP: style-src 'sha256-hash...'; Only matching styles load.
What is strict-dynamic?
strict-dynamic allows scripts loaded by trusted scripts (e.g., <script src='' nonce='abc'> dynamically loads another script). It relaxes whitelist for dynamically loaded scripts. Requires nonces or hashes on root scripts. Modern CSP feature for SPAs.
How do I prevent clickjacking with CSP?
Use frame-ancestors 'self'; to allow only same-origin iframes. Or frame-ancestors 'none'; to block all iframes. This prevents your site from being embedded in iframes on attacker's domain (clickjacking).
Can I use CSP in a meta tag instead of HTTP header?
Yes. <meta http-equiv='Content-Security-Policy' content='...'/>. But some directives (frame-ancestors, report-uri, sandbox) do not work in meta tags. HTTP header is preferred for full CSP support.
Where can I see CSP violation reports?
Browser DevTools Console shows violations (red errors). For server-side monitoring, set report-uri /csp-report; CSP sends POST requests with violation details to that endpoint. Use services like report-uri.com or self-host an endpoint.