CSP Generator: How to Build a Production-Ready Content-Security-Policy Header

A csp generator is the fastest way to build a working Content-Security-Policy header without breaking your production applications. If you are wondering what is CSP, it is a powerful HTTP response header that prevents cross-site scripting (XSS), clickjacking, and data injection attacks by dictating exactly which dynamic resources are allowed to load and execute on your web pages. However, hand-writing a CSP from scratch is notoriously difficult and error-prone. A single typo or a forgotten third-party domain can instantly break your checkout flow, disable your analytics, or render your application unusable. CSP generators solve this problem by providing a structured, interactive way to draft your initial policy. They help you define your rules, but they only get you to the first draft. The real work begins when you deploy that policy in report-only mode and monitor the results.

What a CSP generator actually does

A CSP generator translates your application’s resource requirements into the strict syntax required by the W3C CSP Level 3 specification. Instead of manually typing out long strings of domains, nonces, and directives—and hoping you didn’t miss a semicolon—a generator provides a structured interface. It asks you what external services you use, whether you need inline scripts, and where your API endpoints live. It then compiles these requirements into a valid HTTP header string.

The directives a generator must cover

A robust CSP generator must support the full spectrum of modern CSP directives. The most critical directive is default-src, which acts as the fallback for most other fetch directives. If a specific directive like font-src is omitted, the browser will fall back to the rules defined in default-src.

Beyond the default, a generator must allow you to configure script-src to control JavaScript execution, style-src for CSS, img-src for images, and connect-src for XHR, WebSockets, and Fetch API calls. It should also cover frame-src for embedded iframes (like YouTube or Stripe), font-src for web fonts, and worker-src for Service Workers and Web Workers. Crucially, a modern generator must also help you configure report-uri and report-to directives, which are essential for monitoring violations.

Why hand-writing a CSP is risky for revenue flows

Hand-writing a CSP is a high-risk endeavor, especially for applications with complex revenue flows like ecommerce checkouts or SaaS billing portals. Modern web applications rely on a tangled web of third-party dependencies: payment gateways, analytics trackers, customer support widgets, and A/B testing scripts.

If you manually write a CSP and forget to include the domain for your payment processor’s JavaScript SDK in your script-src, or fail to allow their API endpoint in your connect-src, the browser will block the transaction. The user will see a broken checkout button, and your company will lose revenue. Furthermore, third-party services often load additional resources from secondary domains that you might not be aware of. A generator helps mitigate this risk by providing templates for common services, but even the best generator cannot replace the need for rigorous testing.

The five-step CSP generation workflow

Generating a CSP is not a one-and-done task. It is a continuous process of discovery, drafting, validation, and enforcement. To successfully deploy a CSP without causing outages, you must follow a disciplined workflow.

Step 1 – Inventory every script your production site runs

Before you even open a CSP generator, you need to know what your application is actually doing. You must inventory every single script, stylesheet, image source, and API connection that your production site relies on. This includes your own first-party assets, but more importantly, it includes all third-party integrations.

Talk to your marketing team to find out what tracking pixels they have injected via Google Tag Manager. Check with your sales team to see what chat widgets they are using. Inspect the network tab in your browser’s developer tools while navigating through your application’s critical paths. Document every domain and the type of resource it provides.

Step 2 – Pick a source-allowlist strategy (allowlist vs. nonce vs. hash)

Once you have your inventory, you need to decide how you will authorize these resources. You have three primary strategies: allowlists, nonces, and hashes.

An allowlist strategy involves explicitly listing the domains that are permitted to load resources (e.g., https://js.stripe.com). This is the most common approach but can be vulnerable to bypasses if you allowlist a domain that hosts JSONP endpoints or allows user uploads.

A nonce-based strategy involves generating a unique, cryptographically secure random string (a nonce) for every HTTP response and attaching it to your inline scripts and styles. You can read more about how CSP nonces explained work in our dedicated guide.

A hash-based strategy involves calculating the SHA-256, SHA-384, or SHA-512 hash of an inline script or style and including that hash in your CSP. This is ideal for static sites where the inline content never changes. Learn more about CSP hash sources.

Step 3 – Generate the first header in report-only mode

With your inventory and strategy in hand, use a CSP generator to draft your policy. However, you must never deploy this initial draft directly as a Content-Security-Policy header. Doing so will immediately block any resources you forgot to include, breaking your site for real users.

Instead, you must deploy the generated policy using the Content-Security-Policy-Report-Only header. In report-only mode, the browser will evaluate the policy and report any violations to the endpoint specified in your report-uri or report-to directive, but it will not actually block the resources. This allows you to safely observe the impact of your policy in the real world.

Step 4 – Collect violation reports for at least 7 days

Leave your policy in report-only mode for at least 7 days. This duration is critical because web traffic patterns vary throughout the week. You need to capture data from weekend visitors, automated cron jobs, and infrequent administrative tasks to get a complete picture of your application’s resource usage.

During this time, monitor the violation reports closely. You will likely see a mix of legitimate missing domains that you need to add to your policy, and noise from browser extensions, malware on users’ machines, and false positives.

Step 5 – Promote to enforcement mode

Once you have analyzed the reports, updated your generated CSP to include any missing legitimate resources, and are confident that the noise has subsided, you are ready for enforcement. Switch your header from Content-Security-Policy-Report-Only to Content-Security-Policy.

Even after enforcement, you must continue to monitor your violation reports. As your application evolves and new third-party services are added, your CSP will need to be updated to accommodate them.

CSP generator templates by stack

Different web architectures require fundamentally different CSP strategies. A policy that works perfectly for a static blog will completely break a dynamic Single-Page Application (SPA). Here are some common templates to get you started. You can find more CSP header examples in our comprehensive library.

Static marketing site (Astro, Next.js export, Hugo)

Static sites are the easiest to secure because their assets are known at build time. You can often use a strict allowlist or hash-based approach, completely eliminating the need for unsafe-inline.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=';
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://www.google-analytics.com;
  font-src 'self';
  report-to csp-endpoint;

A strict, hash-based CSP ideal for static site generators like Astro or Hugo.

Single-page app (React, Vue, Svelte)

SPAs often require more permissive policies, especially if they rely on CSS-in-JS libraries that dynamically inject styles, or if they use Webpack’s hot module replacement during development. A nonce-based approach is highly recommended for SPAs rendered on the server (SSR), while pure client-side SPAs may need to rely on strict allowlists.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-r4nd0m123' https://apis.google.com;
  style-src 'self' 'nonce-r4nd0m123';
  img-src 'self' data: https://images.unsplash.com;
  connect-src 'self' https://api.myapp.com wss://ws.myapp.com;
  frame-src 'none';
  report-to csp-endpoint;

A nonce-based CSP designed for modern, server-rendered SPAs like Next.js or Nuxt.

Ecommerce checkout (Shopify, WooCommerce, custom Stripe)

Ecommerce sites must balance strict security with the complex requirements of payment gateways and fraud detection scripts. These third parties often require broad permissions, including the ability to frame other domains and connect to various APIs.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.stripe.com https://www.paypal.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https://*.stripe.com;
  connect-src 'self' https://api.stripe.com https://www.paypal.com;
  frame-src https://js.stripe.com https://hooks.stripe.com;
  report-to csp-endpoint;

A pragmatic CSP tailored for ecommerce checkouts utilizing Stripe and PayPal.

SaaS dashboard with third-party widgets

SaaS dashboards often integrate heavily with third-party tools like Intercom for support, Datadog for RUM, and LaunchDarkly for feature flags. These integrations require careful allowlisting across multiple directives.

Choosing between allowlist, nonce, and hash

When using a CSP generator, you must choose the right authorization strategy for your inline scripts and styles. The choice depends entirely on your application’s architecture.

Strategy	Maintenance Burden	Strictness	Best Fit
Allowlist	Low. Just add domains to the list.	Low. Vulnerable to bypasses if allowlisted domains are compromised or host JSONP.	Legacy applications, simple static sites, third-party heavy sites.
Nonce	High. Requires server-side rendering to generate and inject a unique nonce per request.	High. Protects against XSS even if an attacker can inject a script tag.	Modern SSR frameworks (Next.js, Remix, Nuxt), dynamic web apps.
Hash	Medium. Requires updating the hash every time the inline script or style changes.	High. Cryptographically guarantees the integrity of the inline content.	Static sites (Astro, Hugo), SPAs with immutable inline initialization scripts.

Free CSP generator tools, compared

The market offers several tools to help you build your policy. Here is how the top free CSP generator tools compare.

Tool	Free Tier	Signup Required	Supports Nonce	Supports report-to	Monitoring Layer	Open Source
csper.io generator	Yes	No	Yes	Yes	No	No
Google CSP Evaluator	Yes	No	N/A	N/A	No	No
Report URI generator	Yes	No	Yes	Yes	No	No
CSPify	Yes	Yes	Yes	Yes	Yes	No

csper.io generator

The csper.io generator is a popular, straightforward tool. It provides a clean UI for selecting directives and adding domains. It is excellent for quickly drafting a basic allowlist-based policy. However, it lacks an integrated monitoring layer, meaning you will need to set up a separate service to collect and analyze your violation reports.

Google CSP Evaluator

While technically an evaluator rather than a generator, the Google CSP Evaluator is an indispensable tool in the CSP workflow. Once you have generated your policy, you should paste it into the evaluator. It will analyze your directives and flag potential bypasses, such as allowlisting domains known to host JSONP endpoints or angular libraries that can be exploited for XSS.

Report URI generator

Report URI offers a solid generator as part of its broader suite of security header tools. It guides you through the process of building a policy step-by-step. Like csper.io, it is a great starting point, but its true power is unlocked when combined with their paid reporting service.

CSPify (CSP Builder + monitoring layer)

CSPify takes a different approach by combining a visual Build your CSP for free tool with a powerful, integrated monitoring layer. Instead of just handing you a static string, CSPify helps you deploy that string in report-only mode and immediately begins analyzing the incoming violation reports. It automatically filters out browser extension noise and highlights the exact domains you need to add to your policy to achieve enforcement without breaking your site.

Common mistakes generated CSPs make

Even with a generator, it is easy to inadvertently create a weak or broken policy. Here are the most common mistakes to watch out for.

unsafe-inline and unsafe-eval left in script-src

The most critical mistake is leaving 'unsafe-inline' in your script-src directive. This completely defeats the primary purpose of CSP, which is to prevent XSS attacks by blocking the execution of unauthorized inline scripts. If a generator suggests using 'unsafe-inline', you should strongly consider refactoring your application to use nonces or hashes instead. Similarly, 'unsafe-eval' should be avoided unless absolutely necessary for legacy frameworks.

Missing report-uri / report-to

A CSP without a reporting mechanism is flying blind. If you enforce a policy without report-uri or report-to, you will have no visibility into what resources are being blocked. When your checkout breaks, you won’t know why. Always configure reporting, even in enforcement mode.

Forgetting frame-ancestors (clickjacking)

Many developers focus entirely on fetch directives and forget about frame-ancestors. This directive replaces the older X-Frame-Options header and protects your site from clickjacking attacks by controlling which external domains are allowed to embed your site in an iframe.

Wildcards in connect-src

Using wildcards (e.g., https://*) in your connect-src or script-src directives is extremely dangerous. It allows resources to be loaded from any subdomain, including those controlled by attackers. Always be as specific as possible when allowlisting domains.

What to do after the generator hands you a header

The generator has given you a string. Your work is only half done.

Wire up reporting

Your first step is to configure your web server, CDN, or application framework to send the Content-Security-Policy-Report-Only header along with your generated string. You must ensure that the report-uri or report-to directives point to a valid endpoint capable of ingesting and parsing JSON violation reports.

Watch for noise vs. real regressions

Once reporting is active, you will start receiving data. You must learn to distinguish between actionable reports (e.g., a missing Google Analytics domain) and noise. Noise often comes from browser extensions injecting scripts into the page, or from older browsers that don’t fully support CSP Level 3. Use a CSP evaluator to continuously audit your policy as you refine it based on these reports.

Frequently asked questions

Conclusion

Building a Content-Security-Policy doesn’t have to be a guessing game. A CSP generator provides the essential scaffolding to get your first draft off the ground quickly. However, the generator is only the first step. To achieve true security without sacrificing application stability, you must embrace the report-only workflow.

By inventorying your assets, choosing the right strategy, and rigorously monitoring violation reports, you can confidently deploy a strict CSP that protects your users and your revenue. For further reading, consult the MDN Content-Security-Policy reference and the OWASP Cheat Sheet for Content Security Policy.

Ready to secure your application? Build your CSP for free using our interactive tool, or Start CSPify free to generate your policy and instantly monitor what it would block in production.