CSP Header Generator

CSP header generator - a Content-Security-Policy without guesswork

The CSP header generator assembles a Content-Security-Policy from the ten directives that decide how well a page resists code injection. Fill in the source lists, choose an HTTP header or a <meta> tag, and copy the finished line into your server configuration.

What this tool really does

The form takes ten directives with source lists, from default-src to frame-ancestors. Empty fields are skipped, extra whitespace collapsed and repeated sources inside one directive dropped: the header travels with every response, so its length matters. Semicolons and double quotes are filtered out so a pasted value cannot break the header.

You get the result as a Content-Security-Policy: … line for the server, or as a <meta http-equiv> tag. The HTTP header is the complete version: the meta variant supports neither frame-ancestors nor report-uri nor sandbox, so the generator leaves it out in that mode.

The directives the generator sets

Two entries on that list close the common ways around a policy. object-src 'none' disables legacy plugins that used to run code despite a strict script-src. base-uri 'self' blocks a swapped <base href> that would point relative script paths at a foreign server.

How to roll out CSP without breaking the site

1. Send the policy under the Content-Security-Policy-Report-Only name first. The browser then blocks nothing and only reports violations.
2. Click through the site, especially pages with maps, payments, chat widgets and video - that is where missing domains surface.
3. Add the addresses from the reports and confirm the header reaches the browser with the HTTP headers analyzer.
4. Once the reports stay quiet for a few days of normal traffic, rename the header to Content-Security-Policy and it starts to enforce.

You add the header in the server configuration: on Apache through Header always set in .htaccess (the .htaccess file generator helps), on nginx through add_header in a location block (nginx location block configurator).

Header always set Content-Security-Policy "default-src 'self'; object-src 'none'"

Why 'unsafe-inline' in script-src removes the protection

CSP stops XSS at one point: it refuses to run a script you never declared. An injected <script>alert(1)</script> is precisely an inline script. Once 'unsafe-inline' appears in script-src, the browser executes any code embedded in the HTML, including code that arrived through a comment field. The most common attack path then goes through untouched. The same applies to 'unsafe-eval', which reopens eval().

Instead of 'unsafe-inline', use a single-use nonce: the server draws a random value for every response and puts it in the header and in the nonce attribute of trusted tags. An attacker does not know that value, so the injected code never runs. For fixed blocks a 'sha256-…' hash of the exact script body works instead - the crypto hash generator produces the digest.

frame-ancestors, X-Frame-Options and upgrade-insecure-requests

frame-ancestors decides who may place the page in an iframe, and it supersedes the older X-Frame-Options. The old header only understands DENY and SAMEORIGIN, accepts no domain list, and its ALLOW-FROM variant never worked in Chrome. When both are present, browsers honour the CSP directive.

It is also worth adding upgrade-insecure-requests. This directive takes no source list - its presence makes the browser rewrite http:// addresses to https:// before the request goes out. It rescues sites after an HTTPS migration with old links to images over HTTP. To see what else loads unencrypted, use the mixed content detector.

Frequently asked questions