CruxDevCruxDev Tools Prompts
security Utility • Zero-Server Privacy • 100% Client-Side

CSP Header Generator

Build Content-Security-Policy headers interactively — configure directives for scripts, styles, images, fonts, frames, and report-uri.

Overview

Assembles a Content-Security-Policy header value from five directive fields - default-src, script-src, style-src, img-src and connect-src - and hands you the header string ready to copy. Includes sensible starting values and updates live as you edit any directive.

How It Works

Edit the five directive inputs; the header value rebuilds on every keystroke in the order default-src, script-src, style-src, img-src, connect-src. Copy the result with the button or by clicking the output. The defaults - 'self' for most directives, 'unsafe-inline' allowed for styles, data: and https: for images - give you a working baseline to tighten rather than a blank slate.

Step-by-Step Usage Guide

  1. Start from the defaults and tighten one directive at a time - default-src 'self' is the anchor.
  2. List every origin your scripts, styles, images and API calls genuinely need in their respective fields.
  3. Copy the header and deliver it as a real response header from your server, CDN or hosting platform.
  4. Test with the browser console open: CSP violations log exactly which directive blocked which resource.

Technical Specifications & Standards

CSP (W3C Content Security Policy Level 3) works by directive: each directive names the sources allowed for one resource type, and default-src provides the fallback for any directive you do not spell out - so setting default-src 'self' alone already blocks third-party scripts, styles, frames and connections. When script-src is present it overrides default-src for scripts entirely; the fallback does not merge. The default style-src value here includes 'unsafe-inline', and that deserves a straight warning: allowing inline styles is common because frameworks sprinkle them, but 'unsafe-inline' in script-src would gut XSS protection, since inline event handlers and injected script tags are exactly what an attacker needs. The modern hardening path is nonces or hashes - script-src 'nonce-<random>' or 'sha256-<hash>' - which allow specific inline code without reopening the door; CSP Level 3 also supports strict-dynamic to let nonce-approved scripts load their own dependencies. This tool emits a header value only: delivery is your job, and a response header is strongly preferred over a <meta http-equiv> tag, which cannot express all directives (frame-ancestors among them). There is no syntax validation - the tool joins what you type, so a typo produces a directive the browser will warn about in its console.

Targeted Use Cases

  • Writing a first CSP for a site that has none, starting from a permissive baseline and tightening incrementally.
  • Adding connect-src entries when wiring up a new API domain that the current policy silently blocks.
  • Comparing a proposed policy against the current one to review what a change would allow or forbid.
  • Teaching directive fallback: how default-src is overridden wholesale, not merged, by specific directives.

Notes & Gotchas

  • Remove 'unsafe-inline' from script-src wherever possible; use nonces or hashes instead, since inline script permission defeats the XSS protection CSP exists for.
  • Deploy with report-only mode first (Content-Security-Policy-Report-Only) to find breakage before enforcement.
  • Deliver as an HTTP response header, not a meta tag - meta delivery cannot express all directives and reports violations differently.
  • Keep default-src 'self' as the baseline so any directive you forget to configure fails closed rather than open.

Frequently Asked Questions

What does default-src actually control?

It is the fallback for every fetch directive you have not explicitly set - scripts, styles, images, fonts, connections, frames and more. A specific directive like script-src, when present, replaces the default entirely for that resource type rather than adding to it.

Why does my page break after deploying this header?

Almost always a resource the policy does not list: a font from a CDN, an API call to another domain, or inline scripts blocked because script-src lacks a nonce or hash. The browser console names the violated directive for each blocked resource.

Is 'unsafe-inline' always bad?

In script-src, effectively yes - it permits exactly the injection vector CSP exists to stop. In style-src it is common and lower-risk, since inline styles are less dangerous than inline scripts, though nonces or hashes are still stricter.

Does the tool validate my policy?

No. It concatenates your directive fields into the header string. Syntax errors surface only when the browser parses the header and logs warnings, so test with the console open before shipping.