AZ Tools

Content-Security-Policy Builder

Network

Composes a Content-Security-Policy header from a directive-by-directive form. Each directive accepts a space-separated source list (keywords like 'self', 'none', 'unsafe-inline', or scheme/host sources). The tool flags policies that contain unsafe-inline, unsafe-eval, or a wildcard, omits empty directives from the output, and emits both the response header form and the equivalent <meta> tag. Switch to report-only mode while you're rolling a new policy out to production.

Presets
Directives
Header
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
<meta> tag
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'">

An empty directive falls through to default-src. Set default-src 'self' first, then narrow individual sources.

How to use

  1. Start from a preset (Strict locks everything to 'self', Relaxed allows inline + wildcards, API-only blocks navigation).
  2. Edit each directive — leave a field blank to drop it.
  3. Turn on report-only when shipping a new policy: violations are reported but not blocked.

Frequently asked questions

Header or <meta> tag — which should I use?
The HTTP header is preferred. The <meta> form is convenient when you can't edit response headers (static hosts, etc.), but it can't define frame-ancestors or report-uri/report-to, so it's strictly less powerful.
Why is the wildcard a warning?
* in a source list matches any URL, defeating the policy entirely. Pin sources to specific origins or use 'self' instead — if you genuinely need third-party scripts, list them explicitly.

Related tools