Skip to content

Security

CSP Header Generator

CSP Header Generator

Beta

Build a Content-Security-Policy header from presets and per-directive source lists, with a matching meta tag and warnings for unsafe sources.

Use via API
  • Free, no sign-up
  • REST + MCP
  • Updated
  • Reviewed by Olgun Ozoktas

Runs in your browser · nothing is uploaded

Preset

Directives

0 of 12 on

Start with a preset, or switch on a directive and pick its sources.

default-srcFallback for fetch directives that are not set
script-srcJavaScript sources
style-srcStylesheet sources
img-srcImage sources
font-srcFont sources
connect-srcfetch, XHR, WebSocket and EventSource
frame-srcPages this page may load in frames
frame-ancestorsWho may embed this page in a frame
object-src<object> and <embed> content
base-uriURLs allowed in <base>
form-actionWhere forms may submit
upgrade-insecure-requestsLoad http:// subresources over https://

Report-Only mode

Sends Content-Security-Policy-Report-Only: violations are reported, nothing is blocked.

An https:// URL or a path starting with /. Browsers POST a JSON report there for each violation.

HTTP header

Nothing to copy yet. Pick a preset or switch on a directive.

<meta> tag

The equivalent <meta http-equiv> tag appears here.

frame-ancestors, report-uri and sandbox are ignored in a <meta> tag.

Warnings

Warnings show here as you build the policy.

Test a live header in the Security Headers Analyzer

How to Generate a Content-Security-Policy

  1. Start from a preset

    Pick Strict, Typical site or With Google Analytics. Each one switches on a set of directives with sources you can edit. You can also start from nothing and switch directives on one at a time.
  2. Set the sources for each directive

    Use the 'self', 'none', https: and data: buttons, or type a host such as cdn.example.com or https://*.example.com and press Add. A source that is not valid CSP syntax is refused with the reason, and it never reaches the header.
  3. Decide on reporting

    Turn on Report-Only mode to send Content-Security-Policy-Report-Only, which reports violations without blocking anything. Add a report-uri URL if you collect those reports.
  4. Read the warnings and copy the result

    Check the warnings list, then copy the HTTP header for your server or CDN config. Copy the <meta> tag only if you cannot set headers; it leaves out the directives a <meta> tag cannot carry.

Common Use Cases

Adding a first CSP to an existing site

Start from the Typical site preset, switch on Report-Only, deploy the header and watch the reports before you enforce it. Nothing breaks while you learn which sources the site really uses.

Allowing Google Analytics or Tag Manager

The With Google Analytics preset adds the Google Tag Manager and Google Analytics host patterns from Google's own CSP guidance to script-src, img-src and connect-src.

Blocking clickjacking

Set frame-ancestors to 'none' (no site may frame the page) or 'self' (only your own origin may). Send it as a header, because a <meta> tag cannot carry it.

Reviewing a policy someone else wrote

Rebuild it here directive by directive and read the warnings: 'unsafe-inline' or 'unsafe-eval' in script-src, a wildcard, data: for scripts, or a missing object-src, base-uri or frame-ancestors.

Why Use a CSP Header Generator?

A Content-Security-Policy tells the browser which origins may supply scripts, styles, images, frames and connections for a page, so an injected script from an unlisted source is refused. Writing one by hand is error-prone: keywords must be single-quoted, 'none' cannot share a list, and some directives do nothing in a <meta> tag. This generator builds the policy from switches and source lists, quotes keywords for you, rejects malformed sources before they reach the header, and flags the choices that weaken the policy.

The CSP Header Generator builds a Content-Security-Policy from a list of directives and sources and gives you three things: the HTTP header line, an equivalent <meta http-equiv> tag, and a list of warnings about the policy. Keywords such as 'self' and 'none' are quoted for you, directives come out in a fixed order, and a source that is not valid CSP syntax (a URL with a missing colon, a host with a space, a quote or an angle bracket) is refused before it can reach the header. The policy is built in your browser and nothing you enter is uploaded.

The warnings check what the policy text itself says: 'unsafe-inline', 'unsafe-eval', *, data: or a bare https: in the script sources; 'none' mixed with other sources; plain http:// hosts; and a missing default-src, object-src 'none', base-uri or frame-ancestors. It does not fetch your site, so to see the header a server really sends, use the Security Headers Analyzer. For cookies set by the same response, the Cookie Analyzer checks the Secure, HttpOnly and SameSite flags.

A CSP is one layer of defence against cross-site scripting, not a replacement for escaping output. It pairs well with checking the links you publish in the URL Safety Checker and with the other head tags a page needs, which the Meta Tag Generator writes.

How it compares

You can write a CSP by hand in a text editor, and for a two-directive policy that is often quickest. The trouble starts with the details the browser is strict about: keywords need single quotes, 'none' is ignored as soon as anything else shares its list, and frame-ancestors, report-uri and sandbox are silently ignored in a <meta> tag. A typo in a handwritten policy is not an error message, it is a source that quietly does not match. This generator checks the syntax of every source as you add it and writes the <meta> variant without the directives it cannot carry.

Browser developer tools are the right place for the next step: once a policy is live, the console lists every blocked resource with the directive that blocked it. Framework and server middleware that inject a per-request nonce are the right answer for inline scripts on dynamic sites, because a nonce must change on every response, which no static generator can do for you. Use this page to design and sanity-check the policy, then let your server send it.

Tips for a Working CSP

  • Deploy in Report-Only mode first. An enforced policy that misses one CDN host will break that part of the site for every visitor.
  • Set object-src 'none' and base-uri 'self' (or 'none') explicitly. object-src would otherwise inherit a looser default-src, and base-uri does not inherit from default-src at all.
  • default-src only covers fetch directives. frame-ancestors, form-action and base-uri do not fall back to it, so set them explicitly.
  • Prefer nonces or hashes to 'unsafe-inline' for scripts. In CSP Level 2 and later, a browser ignores 'unsafe-inline' when a nonce or hash is present in the same directive.
  • After you deploy, test the live response with the Security Headers Analyzer to confirm the header your server really sends.

Frequently Asked Questions

What does a CSP header generator do?

It turns a set of directives (default-src, script-src, img-src and so on) and their allowed sources into a valid Content-Security-Policy header line. This one also writes the matching <meta http-equiv> tag, quotes keywords such as 'self' for you, refuses sources that are not valid CSP syntax, and lists warnings for choices that weaken the policy, such as 'unsafe-inline' in script-src.

Should I use the HTTP header or the <meta> tag?

Use the HTTP header whenever you can set one. A policy delivered in a <meta http-equiv="Content-Security-Policy"> tag ignores frame-ancestors, report-uri and sandbox, cannot be Report-Only, and only applies to content that loads after the tag is parsed. The generator leaves those directives out of the <meta> tag and says which ones it dropped.

Why does frame-ancestors not appear in the meta tag?

The CSP specification says browsers must ignore frame-ancestors in a policy delivered by a <meta> element. It only takes effect in the Content-Security-Policy HTTP header, which is why the generator keeps it in the header and removes it from the tag.

Is 'unsafe-inline' always dangerous?

In script-src it allows any inline script to run, including one an attacker injects, which removes most of what a CSP protects against. In CSP Level 2 and later, a browser ignores 'unsafe-inline' when the same directive also contains a nonce or a hash, which lets you keep it as a fallback for older browsers; the generator does not warn in that case. In style-src the risk is lower, and many sites allow it there.

What is Report-Only mode?

It sends the policy as Content-Security-Policy-Report-Only instead of Content-Security-Policy. The browser checks every resource against the policy and reports violations, but blocks nothing. It is the safe way to trial a policy on a live site. It only works as a header, and browsers ignore upgrade-insecure-requests in it, so the generator leaves that directive out.

Should I use report-uri or report-to?

CSP Level 3 deprecates report-uri in favour of report-to, which names an endpoint declared in a separate Reporting-Endpoints header. Browser support for report-to has differed, so many sites send both. This generator writes report-uri, which browsers still honour; if you also use report-to, add it and its Reporting-Endpoints header yourself.

What does each preset contain?

Strict sets default-src 'none', allows scripts, styles, images, fonts and connections only from your own origin, and sets object-src 'none', base-uri 'none', form-action 'self' and frame-ancestors 'none'. Typical site starts from default-src 'self', allows inline styles, images from any https: host or data: URLs, fonts from data: URLs, and lets your own origin frame the page. With Google Analytics adds Google's Tag Manager and Analytics host patterns to the Typical policy.

Why was my source rejected?

Each source must be a keyword ('self', 'none', 'unsafe-inline' and so on), a nonce or hash, a scheme such as https: or data:, or a host with an optional scheme, a leading *. wildcard, a port and a path. The most common mistakes are a missing colon (https//), a space inside a host, and quotes, commas, semicolons or angle brackets, all of which are refused. A rejected source is never added to the header.

Does this tool check my live website?

No. It checks the policy you build, not a server. To see the Content-Security-Policy header a site actually sends, along with its other security headers, use the Security Headers Analyzer.

Is anything I enter sent anywhere?

Not from this page. The policy is built by code running in your browser and nothing you type is uploaded. The same generator is also available through the FindUtils REST API and as the csp_generate MCP tool; a call there sends your directives to FindUtils over TLS to build the policy, and they are not stored or logged.

Rate This Tool

0/1000

Get Weekly Tools

Suggest a Tool