CSP Header Builder

Build Content Security Policy headers interactively. Select directives, choose presets or add custom sources, and generate the full CSP header ready to copy into your server config.

Content-Security-Policy:
HTML <meta> tag:
Apache (.htaccess):
Nginx:

About Content Security Policy

Content Security Policy (CSP) is an HTTP response header that helps prevent cross site scripting (XSS), clickjacking, and other code injection attacks. It works by specifying which content sources the browser should trust.

Key Directives

  • default-src - Fallback for all fetch directives not explicitly set
  • script-src - Controls which scripts can execute
  • style-src - Controls which stylesheets can load
  • img-src - Controls which images can load
  • connect-src - Controls fetch, XHR, WebSocket destinations
  • font-src - Controls which fonts can load
  • frame-src - Controls which URLs can be embedded in iframes

Source Keywords

  • 'self' - Same origin only
  • 'none' - Block everything
  • 'unsafe-inline' - Allow inline scripts/styles (weakens CSP)
  • 'unsafe-eval' - Allow eval() and similar (weakens CSP)
  • https: - Any HTTPS source
  • data: - Allow data: URIs

Related Tools

Content Security Policy Without Breaking Your Site

Content Security Policy is the single most effective browser-side defense against cross-site scripting and data injection. A correctly tuned CSP shrinks the XSS attack surface by 95%+ — but a too-strict policy breaks the site, and a too-lax policy provides no protection. The middle ground takes deliberate engineering, which is why most production sites either ship a permissive CSP, ship one only in report-only mode, or skip it entirely.

How CSP works

The browser receives a Content-Security-Policy header (or meta tag) listing directives. Each directive controls one type of resource:

  • script-src — JavaScript sources.
  • style-src — CSS sources.
  • img-src, font-src, media-src — media.
  • connect-src — XHR, fetch, WebSocket targets.
  • frame-src / frame-ancestors — iframe rules and clickjacking protection.
  • default-src — fallback when a more-specific directive isn't set.

Sources can be hosts (https://cdn.example.com), schemes (data:, https:), keywords ('self', 'none', 'unsafe-inline'), nonces ('nonce-abc123'), or hashes ('sha256-...').

Strict vs. nonce-based vs. hash-based

  • Strict (allowlist). Easy to write but doesn't block bypasses through trusted CDNs that host arbitrary user content (jsDelivr, Google's URL shortener).
  • Nonce-based. Server generates a random nonce per request, includes it in both the CSP header and every inline <script nonce="...">. Inline-script XSS is blocked outright.
  • Hash-based. Lock specific inline scripts to their SHA-256 hash. Best for static sites where scripts don't change between requests.

Modern guidance: combine 'strict-dynamic' with a nonce for SPAs, or use hashes for static sites. Pure allowlist policies are increasingly considered legacy.

Common pitfalls

  • Forgetting connect-src for analytics. Google Tag Manager, Sentry, Mixpanel all hit external endpoints. Fingerprint these in DevTools first.
  • 'unsafe-inline' defeats the purpose. If your script-src has it, you've allowed every XSS payload in the world.
  • data: in script-src. Allows base64-encoded payloads to execute as scripts. Treat as an unintentional bypass.
  • Inline event handlers (onclick="..."). Blocked by default. Refactor to addEventListener or use nonces.
  • Browser extensions. Some inject scripts that violate strict CSPs. Use report-only first to whitelist common ones if needed.

The right rollout

Always ship in Content-Security-Policy-Report-Only first with a report-uri endpoint. Watch the violation reports for two weeks. Tighten the policy. Switch to enforcing mode only when reports stop. For deeper coverage, see our guide on API security in 2026.

Frequently Asked Questions

Should I use 'unsafe-inline' in script-src?

Almost never — it disables the main XSS protection CSP provides. Use nonces or hashes instead.

What is the difference between frame-src and frame-ancestors?

frame-src controls what your page can embed. frame-ancestors controls who can embed your page (replaces X-Frame-Options).

Why are my Google Fonts blocked by CSP?

Add fonts.googleapis.com to style-src and fonts.gstatic.com to font-src.

Can I have multiple CSP headers?

Yes — browsers intersect them, taking the most restrictive. Useful for edge-injected default policies plus app-specific overrides.