Content Security Policy Generator Guide: Stop XSS Before It Starts

Cross-Site Scripting (XSS) remains one of the most common — and most damaging — web vulnerabilities. Every time your browser loads a page, it trusts whatever HTML, JavaScript, and styles the server delivers. If an attacker can slip their own script into that trusted stream, they can hijack sessions, steal data, and pivot to deeper attacks. A Content Security Policy (CSP) is a powerful HTTP header that tells the browser exactly which sources are allowed to load and execute, shrinking the attack surface dramatically even when a bug lets injected content through.

A well-configured CSP is one of the highest-leverage security controls you can ship. But hand-crafting a policy from scratch is error-prone: get a directive wrong and you break your app, get it too permissive and you gain nothing. The Content Security Policy Generator removes that friction. It gives you an interactive UI for assembling directives, a set of sensible presets, and live validation so you can ship a strong policy in minutes — no browser debugging required.

In this guide we'll walk through why CSP matters, how the generator works, the directives and keywords you need to understand, and concrete policies for common real-world apps.

Why Use the CSP Generator?

• Visual directive builder — toggle and populate each directive (script-src, style-src, img-src, and more) instead of memorizing the spec. What you see in the UI is exactly what ends up in the header.
• Battle-tested presets — start from a Development, Production Strict, or CDN Enabled baseline instead of a blank canvas, then customize per project.
• Live validation — the tool flags risky sources like 'unsafe-inline' in script-src and validates source values against the CSP grammar as you type, so mistakes surface before deploy.
• Covers the full directive set — beyond fetch directives, you also get base-uri and form-action, which close off subtle injection vectors many tutorials skip.
• Instant copy-paste output — get a single clean header string ready for your web server config, or a <meta> tag for static hosts where you can't set headers.
• No signup, no tracking, free forever — the tool runs entirely client-side. Your policy never leaves your browser.

Key Features

• Presets are starting points, not finishes lines. They give you a defensible baseline that you then tailor to the specific origins your app actually loads.
• Validation catches the dangerous defaults. The tool deliberately surfaces 'unsafe-inline' because it's the single most common reason a CSP fails to stop XSS — better to see the warning in the UI than in a postmortem.
• Hash and nonce sources make it practical to keep a strict CSP even when you have inline scripts or styles you can't easily refactor.

How to Use the CSP Generator

1. Pick a preset or start blank. For an existing app, start from Production Strict and loosen as needed. For a greenfield project, Development gets you running fast, then you tighten.
2. Add allowed sources per directive. List the exact origins you trust — your CDN, your API host, your font provider. Avoid wildcard schemes like https: unless you have a specific reason.
3. Review validation warnings. Anything flagged in script-src deserves scrutiny; for other directives, confirm each warning reflects a real, intentional choice.
4. Copy the generated header. The output box gives you the exact Content-Security-Policy value to paste into your server config or a <meta http-equiv="Content-Security-Policy"> tag.
5. Deploy and test. Start with Content-Security-Policy-Report-Only to catch violations without breaking the page, then promote to enforcing once your reports are clean.

Understanding CSP Directives

CSP works through fetch directives, each governing a class of resource. Understanding them lets you build a policy that's both tight and functional.

• default-src is the fallback. Any directive you don't explicitly set inherits from default-src. A common strategy is to set default-src 'none' and then explicitly allow each resource type you need.
• script-src is the front line against XSS. It controls where JavaScript (and WebAssembly) can load and execute from. Locking this down is the single most important CSP decision you'll make.
• style-src governs stylesheets and inline styles. Inline styles are common, so you'll often need nonces or hashes here.
• img-src controls image sources, including data: URIs and external image CDNs.
• connect-src restricts where JavaScript can send data via fetch, XHR, WebSockets, and EventSource — critical for preventing data exfiltration even if a script gets injected.
• frame-src and object-src control embedded frames and plugins (Flash, Java, PDF readers). Setting object-src 'none' kills an entire class of legacy attack surface.
• base-uri restricts the <base> tag, preventing an attacker from relocating where relative URLs resolve.
• form-action restricts where forms can submit, blocking form-action-based exfiltration even when XSS succeeds.

CSP keywords control the most common trust decisions:

• 'self' — same origin as the page. Your safest and most-used source.
• 'none' — block everything in this directive. Use as the default-src baseline.
• 'unsafe-inline' — allow inline &lt;script&gt;/&lt;style&gt;. Convenient but it largely defeats CSP's XSS protection; use hashes or nonces instead.
• 'unsafe-eval' — allow eval&#40;). Often needed by legacy bundlers; avoid when possible.
• 'nonce-<random>' — allow inline elements tagged with a matching per-request nonce.
• 'sha256-...' / 'sha384-...' / 'sha512-...' — allow inline content whose hash matches a known-good value.

A representative strict production policy looks like:

Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-abc123';
  style-src 'self' 'nonce-abc123';
  img-src 'self' data:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  frame-src 'none';
  frame-ancestors 'none';
  report-uri /csp-report;

This policy loads everything from the same origin, gates inline scripts and styles on a nonce, allows images and fonts, restricts API calls to one backend, and disables plugins, frames, and form submissions elsewhere.

Practical Use Cases

SaaS Dashboard

A dashboard typically loads from one origin and talks to one API.

Content-Security-Policy:
  default-src 'none';
  script-src 'self';
  style-src 'self';
  img-src 'self' data: https://avatars.example.com;
  font-src 'self';
  connect-src 'self' https://api.example.com wss://api.example.com;
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  frame-src 'none';

Use the Production Strict preset as a starting point, then add your avatar CDN and WebSocket endpoint.

E-commerce Checkout

Checkout pages are high-value targets. Lock them down hard and use a nonce for any necessary inline script.

Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-xyz789' https://js.stripe.com;
  style-src 'self' 'nonce-xyz789';
  img-src 'self' data: https://images.example.com;
  font-src 'self';
  connect-src 'self' https://api.stripe.com;
  base-uri 'self';
  form-action 'self' https://hooks.stripe.com;
  object-src 'none';
  frame-src https://js.stripe.com;

Note that form-action is relaxed only for the payment provider, and frame-src is scoped to the payment iframe.

Static Marketing Site with a CDN

Static sites on a CDN often need slightly looser image and font rules but can otherwise stay strict.

Content-Security-Policy:
  default-src 'none';
  script-src 'self' https://cdn.jsdelivr.net;
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  img-src 'self' data: https:;
  font-src 'self' https://fonts.gstatic.com;
  connect-src 'self';
  base-uri 'self';
  form-action 'self';
  object-src 'none';

The CDN Enabled preset ships a very similar baseline.

Single-Page App with an API

SPAs tend to need a nonce for inline bootstrap scripts and a single API origin for connect-src.

Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-<per-request>';
  style-src 'self' 'nonce-<per-request>';
  img-src 'self' data:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  base-uri 'self';
  form-action 'self';
  object-src 'none';
  frame-ancestors 'none';

Generate the nonce server-side per request and inject it into both the header and the matching &lt;script nonce="..."&gt; tags.

Best Practices

• Start with Report-Only mode. Ship Content-Security-Policy-Report-Only first and collect violations. Promote to enforcing only when reports are quiet.
• Tighten gradually. Begin permissive enough to keep the site working, then remove sources and keywords in small steps, testing after each change.
• Avoid 'unsafe-inline' in production script-src. It's the one keyword that essentially disables CSP's XSS protection. Replace it with nonces or hashes.
• Prefer nonces and hashes. They let you allow specific inline content without opening the door to arbitrary inline scripts.
• Always set object-src 'none'. Plugins are a legacy attack surface with no legitimate modern use; disable them everywhere.
• Test after every change. CSP bugs manifest as broken functionality, not visible errors. Click through critical flows after each edit to your policy.

Ready to lock down your site? Open the Content Security Policy Generator, pick a preset, and ship a strong policy in minutes.

Related Tools You Might Like

Once your CSP is in place, these tools pair well with it:

• SRI Hash Generator — integrity-check third-party scripts.
• htaccess Generator — set security headers via Apache.
• CORS Header Generator — control cross-origin access.

Stay secure out there!