CSP Header Generator

{{ summaryHeading }} {{ summaryValue }} {{ summaryLine }} {{ deliveryLabel }} {{ scriptModelLabel }} {{ rolloutBadge }}

Policy profile:

Profiles replace the core policy fields with reviewable starting values; they never inspect a live site.

Header delivery:

Start report-only for new policies; enforce only after violation data and critical journeys have been reviewed.

Script trust model:

The selected trust model changes the generated script-src directive and rollout checks.

Nonce value:

The visible placeholder is intentionally flagged as a blocker until replaced by server-side generation.

Script hashes:

Separate hashes with spaces or new lines. Draft placeholders remain rollout blockers.

Script sources:

Keep the list as narrow as the application permits.

Legacy script fallback:

Leave blank for the smallest strict policy, or keep reviewed fallbacks for staged compatibility.

Default sources:

Use 'self' for a conventional app or 'none' when each required fetch directive is defined separately.

Style sources:

Avoid 'unsafe-inline' for new applications; retain it only as a documented migration exception.

Image sources:

A common baseline is 'self' data: https:; remove broad schemes when explicit hosts are practical.

Connection sources:

Name API, telemetry, and WebSocket origins explicitly where possible.

Frame ancestors:

Use 'none' unless same-site or named partner embedding is intentional.

Object sources:

Keep 'none' unless a reviewed legacy plugin is genuinely required.

Base URI:

Use 'none' or 'self' unless templates intentionally need another base URL.

Form destinations:

Use 'self' for ordinary same-origin submissions.

Upgrade insecure requests:

Emit the flag directive for HTTPS deployments while mixed-content migration is being tested.

Block inline event handlers:

Emit script-src-attr 'none' after testing that inline handlers have been removed.

{{ field.label }}:

Reporting endpoint:

Blank omits reporting. Use a reviewed HTTPS collector URL when ready to observe violations.

Report group:

Used only when a reporting endpoint is present.

Legacy report-uri:

Off is neutral. Enable only when compatibility requirements justify emitting both reporting directives.

Require Trusted Types:

Off is neutral. Enable only after the application and browser support path has been tested.

Trusted Types policies:

Separate policy names with spaces.

{{ values.header_text }}

Directive	Value	Posture	Deployment note	Copy
{{ row.directive }}	{{ row.value }}	{{ row.posture }}	{{ row.note }}

Priority	Action	Evidence	Next step	Copy
{{ row.priority }}	{{ row.action }}	{{ row.evidence }}	{{ row.nextStep }}

A Content Security Policy (CSP) is a browser policy sent with an HTTP response. It limits where a document may load scripts, styles, images, fonts, frames, workers, media, and network connections. It can also restrict form destinations, embedding parents, inline event handlers, base URLs, and some dangerous DOM script sinks. These restrictions reduce the paths available to cross-site scripting and unwanted content injection, but they do not repair vulnerable application code.

The policy is written as semicolon-separated directives. Each directive governs one behavior and contains source expressions such as 'self', 'none', an HTTPS origin, a nonce, or a script hash. A missing fetch directive may fall back to default-src; directives such as frame-ancestors and form-action do not use that fallback and need their own decisions.

Main decisions in a Content Security Policy rollout
Decision	Purpose	Typical failure
Resource inventory	Name the origins and browser features each route actually needs.	An untested login, checkout, analytics, worker, or error route breaks after enforcement.
Script trust	Authorize scripts with fresh nonces, exact hashes, or a reviewed allowlist.	Broad hosts, `'unsafe-inline'`, or `'unsafe-eval'` leave avoidable execution paths.
Directive scope	Give each resource type the narrowest workable source list.	A broad scheme such as `https:` trusts far more origins than intended.
Rollout mode	Monitor first, then enforce after representative testing.	A draft is enforced before violation evidence and recovery access are ready.

Nonce and hash policies solve different deployment problems. A nonce must be fresh, unpredictable, and repeated on each trusted script element in the same response. A hash authorizes the exact bytes of an inline script and must change when those bytes change. With 'strict-dynamic', a trusted script can load dependencies, which reduces the need for long host lists but makes the trusted script's loading behavior part of the security review.

Content-Security-Policy-Report-Only monitors violations without blocking them. It supports an iterative rollout, but reports can contain noise from extensions, injected software, scanners, stale clients, or routes that were never exercised. Content-Security-Policy enforces the policy and can immediately stop scripts, requests, embeds, or submissions that do not match.

A syntactically valid header is only a deployment draft. Confidence comes from sending it on the real response path, exercising critical journeys, inspecting browser console errors and violation reports, narrowing unnecessary sources, and verifying enforced behavior on normal pages, redirects, and error responses.

How to Use This Tool:

Start with the response type and script trust model, then replace every sample value with facts from the application being protected.

Choose a Policy profile as a reviewable starting point. Profiles replace the core directive values; they do not inspect a live site or discover required origins.
Keep Header delivery on report-only for a new policy. Select enforced delivery only after representative violation evidence and a rollback path exist.
Choose Nonce, Hash, or Allowlist for script trust. Replace the nonce or hash placeholder before deployment, or reduce an allowlist to the exact sources the application requires.
Review the core source directives, especially Default sources, Style sources, Connection sources, Frame ancestors, Base URI, and Form destinations. Invalid source expressions block generation.
Use Advanced only for distinct resource lists, violation reporting, or Trusted Types. A reporting endpoint must be HTTPS, and Trusted Types policy names must match the policies the application creates.
Read the Rollout queue before copying the Header set. Any placeholder blocker, high-risk expression, mixed 'none', or enforcement-readiness item needs an explicit resolution.

Interpreting Results:

The header text is the exact draft to review. A directive marked Strict, Scoped, Review, or High risk reflects a deterministic advisory rule, not proof that the application is secure or compatible. For example, data: or a broad HTTPS scheme earns review because its acceptability depends on what that resource type can do in the application.

Blocker means the draft contains a nonce or hash placeholder that must not reach production.
High calls out 'unsafe-eval', script-wide 'unsafe-inline' without a nonce or hash, wildcards, or insecure HTTP sources.
Review identifies enforcement readiness, deprecated reporting compatibility, Trusted Types rollout, or contradictory 'none' usage.
Next records rollout work such as collecting report-only evidence, configuring reporting, or testing critical journeys.

Technical Details:

A CSP source list is a whitespace-separated set of expressions. Quoted keywords, nonce sources, and SHA-256, SHA-384, or SHA-512 hash sources have special grammar. A directive value of 'none' must stand alone to express an empty source list; combining it with another source is contradictory and should be corrected before rollout.

Transformation Core:

The policy moves through a fixed transformation from choices to headers.

Normalize and validate each source list, remove duplicate expressions, and canonicalize recognized quoted keywords, nonces, and hashes.
Build script-src. Nonce mode emits the nonce, 'strict-dynamic', and any legacy fallback sources; hash mode does the same with exact hashes; allowlist mode emits only the entered script sources.
Serialize the core directives in a stable order, followed by optional resource directives, inline-handler blocking, insecure-request upgrading, Trusted Types, and reporting directives.
Join directives with semicolons and select either the report-only or enforcing header name.
When reporting is configured, emit a separate Reporting-Endpoints header and connect the policy to its named group with report-to.

Rule Core:

CSP posture and rollout classification rules
Condition	Classification	Reason
`'unsafe-eval'`, `*`, or an HTTP source	High risk	Allows broad or insecure execution or loading.
`script-src` contains `'unsafe-inline'` without a nonce or hash	High risk	Inline scripts are broadly authorized.
Broad schemes, `data:`, `blob:`, or inline styles	Review	Risk depends on the governed resource type and application need.
Security flag, Trusted Types, or reporting directive	Scoped	The directive has a narrow operational purpose that still needs compatibility testing.
Narrow source list without the conditions above	Strict	No advisory broad-source trigger was found.

Nonce placeholders and draft hash placeholders are classified separately as rollout blockers. A real nonce should be generated with at least 128 unpredictable bits for each response and copied exactly to trusted script tags. A script hash must cover the exact deployed inline-script bytes.

frame-ancestors controls which parent documents may embed the response and does not fall back to default-src. script-src-attr 'none' blocks inline event-handler attributes. upgrade-insecure-requests asks the browser to request insecure subresources through their secure scheme; it does not prove those resources are available over HTTPS.

Rollout Limitations:

The generator does not crawl the site, observe browser traffic, validate server configuration, or contact a reporting collector. Its posture labels are conservative review cues based on the draft text.

Report delivery is best effort and must not be treated as a complete security log.
A route that was not exercised can still fail after enforcement.
CSP reduces some injection consequences but does not replace escaping, sanitization, dependency controls, authentication, authorization, or secure server behavior.
Header support and directive behavior vary by browser version, so test the actual client range required by the application.

References:

Content Security Policy Level 3, W3C, 5 May 2026.
Reporting API, W3C.
How to audit HTTP security headers, Simplified Guide.
How to add a custom response header in Apache, Simplified Guide.