Skip to content

CSP Builder

Builds a Content-Security-Policy from a guided form or from a report, and explains each directive.

Content-Security-Policy is the header that turns a cross-site scripting bug from a compromise into a blocked console message, and it is also the header most often shipped in a form that does nothing. This builds one directive by directive and explains what each is actually preventing.

🔒 Runs entirely in your browsercspheaderswebgenerator
Load an existing policy

The fallback for every fetch directive you do not set explicitly.

Where scripts may load from. The directive that actually stops XSS.

Where stylesheets may load from.

Where images may load from.

Where fonts may load from.

Where fetch, XHR, WebSocket and EventSource may connect.

Where <audio> and <video> may load from.

Where <object>/<embed> may load. Usually best set to 'none'.

Where <iframe> documents may load from.

Who may frame this page — the modern replacement for X-Frame-Options.

What <base href> may be set to. Limit to 'self' or 'none'.

Where forms may submit.

Where Workers, SharedWorkers and service workers may load from.

Where the web app manifest may load from.

Rewrite http:// subresource requests to https://.

Block any http:// subresource outright (legacy).

  • ⚠ No frame-ancestors: add it (e.g. 'none' or 'self') to control who can frame the page.
  • ⚠ No base-uri: add base-uri 'self' to stop <base> tag injection.

Content-Security-Policy

default-src 'self'; script-src 'self'

How to use it

  1. Start from the form or from a report

    The guided form asks where scripts, styles, images and connections come from. If you already have violation reports, paste them and the sources are derived from what actually loaded.

  2. Deploy it in report-only mode first

    `Content-Security-Policy-Report-Only` logs violations without blocking. Run it for a week, and the reports will name the third-party embed nobody remembered.

  3. Remove `unsafe-inline` last, and properly

    A policy with `script-src 'unsafe-inline'` blocks almost nothing. Replace it with a per-response nonce or hashes of the inline blocks — the tool generates both forms.

Common questions

Does the tool test my site?

No. It composes and explains a policy from what you tell it. Checking what a live site currently sends is the security header scanner’s job.

Why is my policy still allowing inline scripts?

A nonce or hash in `script-src` is ignored when `unsafe-inline` is also present in the same directive, for backwards compatibility. Both cannot be kept — the fallback wins.

Is `default-src 'self'` enough on its own?

It is a good base, but several directives do not fall back to it — `frame-ancestors`, `form-action` and `base-uri` among them. Those have to be set explicitly, and this tool sets them.

Feed it from

Next

These accept what this tool produces, so the result can go straight in.