Free Content Security Policy Generator and Security Headers Analyzer

CSP and HTTP Security Headers Builder

Build a Content-Security-Policy step by step, add HSTS, Permissions-Policy and the other security headers, and copy them as Nginx, Apache, Caddy, Traefik, IIS or WordPress config. Or paste the headers a site already sends to see what is missing, broken or unsafe. Nothing leaves your browser.

1. Start from a preset

A preset replaces the CSP directives below. Services and the other headers stay as they are.

2. Content-Security-Policy

Report-Only sends Content-Security-Policy-Report-Only: browsers report what would be blocked but block nothing — the safe way to try a new policy on a live site.

Third-party services

    Hosts come from each vendor’s own documentation. With a strict (nonce) policy, give the vendor’s <script> tag your nonce instead — hosts are then only a fallback for old browsers.

    Directives

    Separate sources with spaces. Keywords need single quotes, such as 'self' and 'none'. An empty field falls back as shown; the buttons add or remove common values.

    Hash an inline script or style

    Paste the exact text between <script> and </script>, or the whole element. Every space counts; line endings are turned into LF, as the HTML parser does.

    —

    Nonces must be new on every response, so they come from your server, not from this page: PHP base64_encode(random_bytes(16)), Node.js crypto.randomBytes(16).toString('base64'), Python secrets.token_urlsafe(16). Example of the format:

    Violation reports

    Adds report-uri and report-to to the CSP plus a Reporting-Endpoints header. You need something that accepts the JSON reports — a small endpoint of your own or a hosted collector.

    3. HTTPS, framing and sniffing

    Raise max-age in steps (5 minutes → 1 week → 30 days → 1 year) and check that nothing breaks in between.

    4. Permissions-Policy

    Switch off browser features your site never uses, so injected or embedded code cannot ask for them. Chromium-based browsers apply this header; Firefox and Safari ignore it for now.

    5. Cross-origin and clean-up

    COOP same-origin-allow-popups is a safe start. Set COEP only if you need cross-origin isolation (SharedArrayBuffer, precise timers): it can block third-party images and embeds.

    Your headers

      Checks

        Headers to analyze

        How to get the headers

        This page does not fetch sites for you: browsers hide most response headers from cross-origin requests (CORS), so a “check URL” button in a web page gives incomplete answers. Copy them yourself — it takes seconds:

        • Linux / macOScurl -sI https://example.com
        • Windowscurl.exe -sI https://example.com
        • BrowserDevTools → Network → reload → click the page → Headers → Response Headers → Raw

        Some servers answer HEAD requests (-I) with fewer headers than GET. For a GET, use curl -s -D - -o /dev/null URL (-o NUL on Windows); add -L to follow redirects.

        Report

        –

        Paste headers to get a checklist of what is good, weak, missing or broken — with the reason for each finding.

          The score covers only the headers you pasted. It is a checklist, not a penetration test.

          Working on the rest of your security setup? Decode session tokens with the JWT Token Decoder, compute checksums with the Hash Generator, or create strong secrets with the Password Generator.

          Built by VahaC — 100% client-side, no data sent anywhere.

          This free content security policy generator builds a CSP one directive at a time, adds the other HTTP security headers (HSTS, Permissions-Policy, X-Frame-Options and friends), and hands you ready-to-paste config for Nginx, Apache, Caddy, Traefik, IIS or WordPress. A second tab grades the headers a site already sends: paste them, and every finding comes with a plain-English reason.

          I built it because a CSP is easy to get almost right. A comma instead of a space, self without quotes or a missing semicolon still looks fine, yet the browser quietly drops the part you wrote. This content security policy generator checks every change as you type and tells you what the browser will actually do with it.

          What This Content Security Policy Generator Does

          • 🧭 Presets to start from: a same-origin starter, Google’s nonce-based “strict CSP”, a compatible preset for themes that print inline scripts, and a lock-down policy for JSON APIs.
          • 🧩 One field per directive: each field shows what it falls back to when empty, with quick-add buttons for 'self', 'none', a nonce placeholder, 'strict-dynamic' and the risky keywords, which are marked in red.
          • 🔌 13 third-party services in one click: Google Analytics 4, Tag Manager, Google Fonts, YouTube, Vimeo, Google Maps, reCAPTCHA, Cloudflare Turnstile, hCaptcha, Stripe, Cloudflare Web Analytics, Plausible and Gravatar, with hosts taken from each vendor’s own documentation.
          • 🔑 Hashes for inline code: paste an inline script or style and the content security policy generator returns its SHA-256, SHA-384 or SHA-512 source, calculated the way the browser calculates it.
          • 🔒 The rest of the headers: HSTS with preload-list checks, X-Frame-Options that follows your frame-ancestors, nosniff, Referrer-Policy, Permissions-Policy for 22 browser features, cross-origin isolation headers and violation reporting.
          • 📦 10 output formats: raw headers, Nginx, Apache, Caddy, Traefik labels or file provider, Netlify and Cloudflare Pages _headers, an HTML <meta> tag, WordPress/PHP and IIS web.config, each escaped for its own syntax.
          • 📊 An analyzer with a score: paste curl -I output, DevTools headers, a bare policy or a <meta> tag and get a 100-point score, a letter grade and a finding for every header.

          How to Use the Content Security Policy Generator

          1. Pick a preset. Starter suits most static and self-hosted sites; choose Strict CSP if your app can put a fresh nonce on every script tag.
          2. Tick the services your pages load, then adjust the directives. The Checks panel updates as you type and flags anything unsafe or invalid.
          3. Set HSTS, framing, Referrer-Policy and Permissions-Policy in the sections below the CSP.
          4. Choose your server under Format; the content security policy generator writes the matching config, ready to copy or download.
          5. Roll the policy out as Report-Only first, fix what the browser console reports, then switch to enforce. To confirm, run curl -sI https://your-site.example and paste the output into the Analyzer tab.

          Why It Reads Pasted Headers Instead of Fetching a URL

          The analyzer in this content security policy generator never asks for a URL, on purpose. A web page can only read another site’s response headers when that site allows it through CORS, and almost no site exposes its security headers that way. A browser-based checker that “fetches” a URL would either see nothing or need its own server to send the request for you. Pasting keeps the whole check on your machine, and it works for intranet hosts, staging servers and homelab dashboards that the internet cannot reach.

          The content security policy generator reads what you paste the way browsers read it:

          • Commas start a new policy, so default-src 'self', https://cdn.example becomes two policies and one broken directive.
          • Missing semicolons turn script-src into a host name inside the directive before it.
          • Unquoted keywords such as self or none match a host with that name, not your own site.
          • Leftover placeholders like 'nonce-{RANDOM}' are reported, and 'strict-dynamic' without a valid nonce or hash is flagged, because it blocks every script.
          • Old syntax is caught too: ALLOW-FROM in X-Frame-Options, Feature-Policy syntax inside Permissions-Policy, and SameSite=None cookies without Secure.

          It also explains why Google recommends a nonce-based policy with 'strict-dynamic': an allowlist that trusts a whole public CDN lets an attacker load any script hosted there, and the analyzer names the risky hosts it finds.

          Practical Use Cases

          A few ways to put the content security policy generator to work, in a homelab or on a public site:

          • 🛡️ Reverse proxy hardening. Add the Nginx lines to the server block of your proxy, or to the Advanced tab of an Nginx Proxy Manager host next to the rules from my CrowdSec with Nginx Proxy Manager guide. The generated comment explains the add_header inheritance rule, the usual reason headers go missing.
          • 🐳 Traefik in Docker. Copy the labels format into your compose file and attach the security-headers middleware to each router.
          • 🌐 Apps you expose to the internet. Before you open a dashboard to the outside world, as in secure remote access to a home server, check that it sends HSTS, nosniff and a CSP.
          • 📝 WordPress. If you run WordPress yourself, like in my WordPress and MariaDB on Docker guide, start with the Compatible preset and the WordPress/PHP output.
          • 🔍 Audits after changes. Paste curl -sI output before and after an upgrade or a proxy migration and compare the two scores.

          Privacy, Ads, and Data Policy

          • ✅ 100% free: no registration and no limits.
          • ✅ No data storage: the content security policy generator never uploads your policies, headers or cookies, and the report does not even display cookie values.
          • ✅ No ads in results: no watermarks and no tracking snippets added to your config.
          • ✅ Client-side only: no external requests at all; the tool never contacts the sites you check.

          Open Source and Self-Hosting

          The content security policy generator is open source on GitHub: three files (index.html, style.css and script.js) with no external libraries and 67 unit tests, ready to drop onto any static web server. If you are hardening containers as well, see my notes on Docker security for self-hosting.

          Like this content security policy generator, every tool on the Tools page runs in your browser, for example the JWT Token Decoder for session tokens and the Hash Generator for checksums.

          Built by VahaC — 100% client-side, no data sent anywhere.