Content Security Policy Generator: Free CSP

A content security policy generator builds a Content-Security-Policy header for you, so you never have to write directives by hand. Pick a preset, adjust the allowed sources for 12 directives such as script-src and frame-ancestors, then copy the result as an HTTP header, an Apache rule, an Nginx line or a meta tag.

What Is a Content Security Policy?

A Content Security Policy (CSP) is a browser security rule, sent in an HTTP response header, that lists the sources a page may load scripts, styles, images, fonts, frames and other resources from. When a page tries to load something from a source that is not on the list, the browser blocks it. That limits the damage of cross-site scripting (XSS), where an attacker manages to inject code into your pages.

A policy is a set of directives separated by semicolons. Each directive names a resource type followed by its allowed sources. For example, script-src 'self' https://cdn.jsdelivr.net means scripts may load only from your own origin and from that one CDN.

Source keywords you will see

• 'self' allows your own origin (same scheme, host and port).
• 'none' blocks everything for that directive, and it must be the only source in the field.
• data: and blob: allow those URL types, which are common for small inline images.
• https: allows any HTTPS source, which is broad, so use it sparingly.
• 'unsafe-inline' and 'unsafe-eval' allow inline code and string-to-code execution. They weaken your protection.

What does default-src 'self' mean?

The directive default-src 'self' tells the browser to load any resource type you have not configured separately only from your own origin. It acts as the fallback for directives you leave out, which makes it a safe starting line for most policies.

How is CSP different from CORS?

CSP controls what your page is allowed to load and where it may connect. CORS controls which other websites may read responses from your server. They solve different problems, and one does not replace the other.

How to Use the CSP Generator

You can go from a blank page to a copy-ready policy in a few minutes. The interface has three numbered parts, and every change updates the output immediately.

1. Under 1. Choose a starting preset, click Strict (lock-down), Balanced (recommended) or Site with Google Analytics. The directive fields fill in automatically.
2. Under 2. Configure directives, open a directive such as script-src or img-src. Type sources like https://cdn.example.com, or click the quick tokens ('self', 'none', data:, blob:, https:).
3. Tick upgrade-insecure-requests if you want browsers to load http links on your pages over HTTPS.
4. To test safely, tick "Use Report-Only mode (test before enforcing)". Add a "Reporting endpoint (optional)" that starts with https:// if you have a collector.
5. Under 3. Copy your policy, switch between the Header, Apache, Nginx and Meta tag tabs, then click "Copy current".
6. Paste the code into your server configuration or the head of your page, then reload and check your site.

Which Preset Should You Start With?

Start with the preset closest to how your site really loads resources, then loosen only what breaks. The three presets differ mainly in how many outside sources they trust.

Worked Example: Adding Google Fonts to the Balanced Preset

Say your blog uses the Balanced preset but loads fonts from Google Fonts. Balanced allows fonts and styles only from your own origin plus two CDNs, so the browser would block the font files and the stylesheet.

You open style-src and add https://fonts.googleapis.com. Then you open font-src and add https://fonts.gstatic.com. The generated policy now contains these two lines among its directives:

• style-src 'self' 'unsafe-inline' https://cdn.jsdelivr.net https://cdnjs.cloudflare.com https://fonts.googleapis.com
• font-src 'self' https://cdnjs.cloudflare.com https://cdn.jsdelivr.net https://fonts.gstatic.com

Everything else stays locked to your own origin, so images, scripts and form submissions are still restricted. Before enforcing, tick Report-Only mode, deploy, and browse your key pages with the browser console open. If no violation messages appear, untick Report-Only and deploy the enforcing version.

How Do You Read and Act on the Output?

The output panel shows the same policy in four formats, plus warnings and errors that tell you what to fix. Use the format that matches where you control your site.

The four output tabs

• Header: the raw header line, for hosting panels, CDNs or application code that sets response headers.
• Apache: a rule for your server configuration or .htaccess file.
• Nginx: an add_header line for your server block.
• Meta tag: an HTML tag for the head section, useful when you cannot edit server headers.

Common errors and the fix

• 'none' must be the only source: remove the other sources in that field, or remove 'none'.
• Inline keyword does not apply here: 'unsafe-inline' belongs only in script-src or style-src. Remove it from other directives.
• Keyword does not apply here for 'unsafe-eval': it works only in script-src.
• Unrecognized quoted source expression: check spelling and quotes. Accepted quoted values include 'self', 'none', 'strict-dynamic', nonce values and sha256, sha384 or sha512 hashes.
• Add at least one policy directive: every field is empty, so pick a preset or type a source.

What Do Report-Only Mode and the Reporting Endpoint Do?

Report-Only mode makes the browser check your policy and report violations without blocking anything, so you can find problems before visitors do. The generator labels the header accordingly, which is why testing first is the safest path to enforcement.

Several things change in this mode. The upgrade-insecure-requests option is ignored and left out, because browsers do not apply it in Report-Only. The meta tag tab is not available for Report-Only, since that mode works only as an HTTP header. Without a reporting endpoint, you will only see violations in the browser console.

If you add an endpoint, it must be an absolute HTTPS address without a username or password. A normal website URL does not collect reports on its own, so use the collector address from your reporting service. Your server also needs to send the matching Reporting-Endpoints response header. The reporting setting appears in header-style output only, not in the meta tag.

Should You Avoid unsafe-inline?

Yes, avoid 'unsafe-inline' in script-src whenever you can. It lets any inline script run, including one an attacker injects, which removes most of the XSS protection a CSP provides.

The better route is to allow specific inline code with a nonce or a hash. You can type values such as 'nonce-abc123' or 'sha256-...' straight into script-src or style-src, and the generator accepts them. It does not create nonce values for you. A nonce must be a fresh random value on every page response, so your application has to generate it and place the same value in the header and on each inline script tag.

Note that the Balanced and Google Analytics presets include 'unsafe-inline' for styles, and the Google Analytics preset also allows it for scripts. Those presets are practical starting points, not final answers. Tighten them once you have moved inline code to files or added nonces.

Who Is This CSP Builder For?

• Site owners who got a missing-CSP warning in a security audit and need a working policy quickly.
• Developers who want a clean first draft of a policy before refining it for a framework or CDN setup.
• WordPress and static site admins who can only add headers through .htaccess, an Nginx config or a head snippet.
• Anyone clickjacking-proofing a site by setting frame-ancestors to 'none' or 'self' to control who can embed their pages.
• Students and teams learning what each directive does by watching the output change as they toggle sources.

Best Practices and Troubleshooting

A good policy is as narrow as your site allows and tested before it is enforced. These habits prevent most problems.

• Test in Report-Only first. Deploy, browse every template type (home, article, checkout, forms), then enforce.
• List only the hosts you actually use. Open your browser's network panel to see which domains your pages call.
• Avoid broad sources. A bare https: in script-src allows scripts from any HTTPS site.
• Set object-src to 'none' unless you embed plugins, and set base-uri to 'self' to stop injected base tags.
• Use frame-ancestors for embedding control. It replaces the older X-Frame-Options approach in modern browsers.
• If a page looks broken after enforcing, open the console. Each blocked resource names the directive that blocked it, so add that host to that directive only.
• If your policy seems ignored, check that two headers are not conflicting and that your cache or CDN is not serving the old response.

Limitations to Know About

The generator builds policy text. It does not scan your site, so it cannot tell which third-party hosts your pages call. You supply those sources, and you confirm the result in a browser.

The directive frame-ancestors works only in an HTTP header, so it is left out of the meta tag output, and you will see a warning saying so. The obsolete block-all-mixed-content option is shown disabled and is never generated; use upgrade-insecure-requests instead. The tool also produces one site-wide policy, so pages that need different rules require separate configuration on your server.

Ready to lock down your site? Choose a preset above, adjust the sources, and copy your policy in Report-Only mode. Once it is live, run your domain through the security headers checker to confirm the header is being sent. If you are also switching a site to HTTPS, you can inspect your SSL certificate with the certificate decoder, and you will find more utilities in the security and encryption tools collection.