CSP Header Generator for Content Security Policy

A Content Security Policy is an HTTP response header that tells a visitor's browser exactly which sources a page may load from — where scripts can come from, which stylesheets, images, fonts, and connections are permitted, and what is forbidden everywhere else. Set up well, it is one of the strongest defences against cross-site scripting, because even if an attacker manages to inject markup into a page, the browser refuses to run scripts from sources the policy does not name. Writing that header by hand means one long, error-prone line of directives. This CSP header generator helps you assemble a correct one from the sources your site actually uses.

The Directives That Shape a Policy

A policy is a list of directives, each controlling one kind of resource. default-src is the fallback for anything not covered separately. script-src governs JavaScript and is the directive attackers care about most. style-src, img-src, font-src, and connect-src cover styles, images, fonts, and fetch or WebSocket connections respectively, while frame-ancestors controls who may embed your pages in a frame — your clickjacking protection. The keyword 'self' means the site's own origin. The keywords 'unsafe-inline' and 'unsafe-eval' switch off key protections for inline code and executed strings, and are best kept out of script-src; a policy that allows them for scripts is much weaker than it looks. A typical finished policy might read: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data:; frame-ancestors 'none'. The full specification is maintained in the Content Security Policy documentation at MDN Web Docs.

What the Generator Helps You Assemble

The generator turns an inventory exercise into a header. You work through the resource types a browser distinguishes — scripts, styles, images, fonts, connections, frames, media, and the default fallback — and name the sources each one is allowed to use: your own origin, specific CDN or service hosts, or keywords such as 'self'. Starting from a restrictive default and opening only the doors your site genuinely needs is the discipline that makes a policy strong, and it is far easier to keep that discipline field by field than in one hand-typed line where a missing semicolon quietly merges two directives. The output is a single header value, ready to copy into your server configuration exactly as produced, so there is no transcription step where a typo can weaken it.

How to Use the CSP Header Generator

1. List what your site genuinely loads: its own files, any CDN hosts, analytics or font services, payment or chat widgets, and embedded media.
2. Enter the allowed sources for each resource type the generator asks about, beginning with your own origin as the default.
3. Be strictest with scripts — avoid 'unsafe-inline' and 'unsafe-eval' in script-src unless you have no alternative.
4. Click Generate CSP Policy to produce the header value.
5. Copy the generated Content-Security-Policy value exactly as produced and add it to your site through your server configuration or hosting panel, as a response header on your pages.
6. Where your setup allows, deploy it first as Content-Security-Policy-Report-Only and read the violation reports to find legitimate resources you forgot.
7. Switch to the enforcing header once reports show only things you actually want blocked, then re-check your key pages in a browser console.

A Short Example of the Process

Imagine a small business site that loads its own styles and scripts, fonts from a font service, and a map embed. The inventory step finds four source groups: the site's own origin, the font host, the map provider, and data: URIs used for a few inline images. The resulting policy keeps default-src at 'self', adds the font host to font-src and style-src as its documentation requires, names the map provider in frame-src, and allows data: only for images. Nothing else is permitted — so if a comment form on the site ever let an attacker inject a script tag pointing at an unknown server, the browser would refuse to load it, which is the entire point. Site owners usually review CSP alongside the rest of their response headers using the security headers auditor, because headers such as Strict-Transport-Security and X-Content-Type-Options work as a set, and a certificate check with the SSL checker rounds out the same audit.

Rolling a Policy Out Without Breaking Your Site

The usual failure mode of CSP is not weakness but breakage: a strict policy applied in one step blocks an inline script, a third-party widget, or a stylesheet the design depends on, and pages render unstyled or stop working. The staged rollout in the steps above exists to prevent exactly that. Other common mistakes: allowing * for script-src, which permits scripts from anywhere and largely defeats the policy; forgetting resources a page loads quietly, such as favicons, web fonts, or images served from a separate media subdomain; copying a policy from another site whose third-party services differ from yours; setting the header on the homepage only, when it protects only the responses it is actually sent with; and never revisiting the policy after adding a new analytics, chat, or payment provider, then wondering why it silently refuses to load.

CSP Questions Site Owners Ask

Does CSP replace careful coding?

No. CSP is a safety net, not a substitute for escaping output and validating input. Its value is that when a bug slips through, the browser still refuses to load or run resources your policy never named, which limits the damage an injection can do.

What does 'self' mean in a directive?

It means the site's own origin — the same scheme, host, and port that served the page. Writing script-src 'self' allows scripts from your own domain while blocking scripts hosted anywhere else.

Why did my page break after I added CSP?

Almost always because something legitimate was not listed: an inline script, a font, a third-party widget, or images from another subdomain. Open the browser console, read which loads the policy blocked, and add only the sources you recognise as yours or your providers'.

What is the difference between the enforcing and Report-Only headers?

The enforcing Content-Security-Policy header blocks anything the policy does not allow. Content-Security-Policy-Report-Only only reports what would have been blocked, which makes it the safe way to test a new policy on a live site before enforcing it.

Should I allow 'unsafe-inline' for scripts?

Avoid it if you can. It permits all inline script on the page, which removes much of the protection CSP exists to give against injected markup. Where inline code cannot be removed, nonces or hashes for specific trusted blocks are the stricter alternatives described in the specification.

Does every page need the header, or just the homepage?

Every response you want protected. A policy only governs the page it is sent with, so the header belongs on all pages of the site, not just the front door — which is why it is normally set once at server or framework level.

A Policy Written From Your Real Site

A Content Security Policy is one of the cheapest meaningful security wins a website can claim, provided it is written from the site's real behaviour rather than copied from a stranger's. Generate yours from the sources you genuinely load, roll it out carefully, and keep tightening it as your pages change.