CSP Header Draft
{{ result.summary.primary }}
{{ result.summary.line }}
{{ badge.label }}
Choose a strict nonce/hash policy for new apps, or an allowlist profile for staged migrations.
Use report-only while collecting violations, then switch to enforced once the generated policy has been proven.
Pick how trusted scripts are identified in the generated script-src directive.
The same value must be emitted on trusted script tags for each response.
Separate hashes with spaces or line breaks; keep the quoted CSP form or paste the bare sha256- value.
Keep this list narrow; unsafe-inline and unsafe-eval are highlighted in the rollout queue.
Use self plus HTTPS while migrating; leave blank for the smallest strict CSP header.
Use self for normal apps, none for very tight policies, or HTTPS only for transitional audits.
Avoid unsafe-inline for new apps; keep it only for staged framework migrations.
Common safe starts are self plus data: for inline icons and HTTPS image hosts.
List API and telemetry origins explicitly; use wss: only when WebSockets are required.
Use none for normal apps, self for same-site embeds, or an explicit partner origin.
Use none unless a legacy plugin surface is intentionally required.
Use none for strict apps or self when templates legitimately emit a base element.
Use self for most apps; add payment or identity origins only when forms post directly to them.
Keep enabled for HTTPS sites unless mixed-content testing shows a deployment issue.
{{ upgrade_insecure_requestsBool ? 'On' : 'Off' }}
Add only if fonts need a different allowlist than default-src.
Use self blob: only when the app actually creates blob workers.
Use none unless this page intentionally embeds trusted frames.
Add only when media needs a separate source list.
Use self for installable web apps that publish a local manifest.
Leave blank to omit reporting headers; use an HTTPS collector URL when monitoring rollout violations.
Use a short token such as csp-endpoint.
Turn on when older reporting collectors still depend on report-uri.
{{ use_report_uriBool ? 'On' : 'Off' }}
Recommended for strict policies unless legacy templates still depend on onclick-style attributes.
{{ script_attr_noneBool ? 'On' : 'Off' }}
Enable only after templates and framework output have been checked for inline style attributes.
{{ style_attr_noneBool ? 'On' : 'Off' }}
Enable after the application has a Trusted Types policy and compatible DOM sink usage.
{{ trusted_typesBool ? 'On' : 'Off' }}
Use default for a first policy, or list named policies separated by spaces.
{{ result.headerText }}
Directive Value Posture Deployment note Copy
{{ row.directive }} {{ row.valueDisplay }} {{ row.posture }} {{ row.note }}
Priority Action Evidence Next step Copy
{{ row.priority }} {{ row.action }} {{ row.evidence }} {{ row.nextStep }}
Tags: HTTP, Security
CSP Header Policy Checker Check a Content-Security-Policy header for risky script rules, missing baseline directives, reporting gaps, and rollout fixes before enforcement.
Hypertext Transfer Protocol (HTTP) Header Checker Check a live URL's HTTP headers, redirect hops, cache semantics, cookies, CORS exposure, and hardening priorities from one report.
HTTP Security Headers Checker Check pasted HTTP response headers for HSTS, CSP, cookies, cache, CORS, and disclosure risks with scoring, fix order, and JSON evidence.
NGINX Proxy Headers Checker Check an NGINX proxy block for forwarded-header gaps, spoofed-client risks, WebSocket handling, timeout mismatches, and fix order.
Customize
Advanced
:

Content Security Policy, usually shortened to CSP, is a browser-enforced response policy for resource loading and document behavior. The policy names which scripts, styles, images, fonts, frames, network connections, form targets, and older plug-in surfaces the browser should allow. A useful CSP reduces the damage from cross-site scripting, unwanted embedding, and accidental mixed-content loading, but it does not replace input validation, output escaping, dependency review, or server-side access control.

Writing the semicolon-separated header is the small part; knowing which browser behaviors the site genuinely needs takes more care. Modern pages often load analytics, identity flows, payment widgets, documentation frames, web fonts, APIs, workers, image CDNs, and inline bootstrapping code. A policy that is too broad can still allow risky script behavior, while a policy that is too narrow can break login, checkout, admin screens, embedded content, or single-page app startup.

Directives
Named rules such as script-src, img-src, connect-src, form-action, and frame-ancestors.
Source expressions
Allowed origins, schemes, keywords, nonces, or hashes inside a directive value.
Fallbacks
default-src can cover several fetch directives, but specific directives override it when present.
CSP planning flow from source inventory to script trust, directives, warnings, and header rollout

Strict CSP usually relies on a nonce or a hash source for trusted scripts, often with 'strict-dynamic'. That pattern is stronger than a long host allowlist because trust follows the script that was explicitly authorized, not every host that appears in a policy. Allowlist policies still have a place during migration, especially when older pages depend on third-party scripts or inline code, but broad entries such as https:, wildcard hosts, 'unsafe-inline', and 'unsafe-eval' should be treated as cleanup work rather than a final state.

Rollout mode is part of the security decision. Content-Security-Policy-Report-Only lets browsers report violations without blocking users, which makes it useful for discovery and staged cleanup. Content-Security-Policy enforces the rules and can stop page features immediately. A good CSP rollout normally moves from inventory, to report evidence, to enforcement, with a rollback plan for routes that were not exercised during testing.

How to Use This Tool:

Build one candidate CSP header for the rollout you are planning, then read the generated header together with the directive ledger, warnings, and rollout queue before copying it into server configuration.

  1. Choose Policy profile. The summary updates to match the selected baseline, such as Strict nonce rollout, Strict hash rollout, Balanced web app, Static site, API documentation site, or Legacy migration audit.
  2. Set Header delivery to Content-Security-Policy-Report-Only while collecting violations, or Content-Security-Policy when the policy is ready to block violations. The Header Set tab changes the header name to match that choice.
  3. Choose Script trust model. Fill Nonce placeholder for nonce mode, Script hashes for hash mode, or Script sources for allowlist mode.
  4. Review the main source fields: Default source, Style sources, Image sources, Connect sources, Frame ancestors, Object source, Base URI, and Form action. The Directive Ledger shows the directive, value, posture, and deployment note for each generated row.
  5. Turn on Upgrade insecure requests when HTTPS pages should ask the browser to upgrade HTTP subresource requests. Open Advanced for font, worker, child-frame, media, manifest, reporting, inline attribute, and Trusted Types settings.
  6. If Fix source expressions appears, correct the named field before using the header. Common causes are semicolons inside source tokens, unsupported quoting, control characters, or a Reporting endpoint that is not a valid HTTPS URL.
  7. Open Rollout Queue and clear blocker rows such as nonce replacement, hash replacement, invalid sources, missing reporting, 'unsafe-eval', or 'unsafe-inline' without nonce or hash control.
  8. Use Header Set for the final header text. Use JSON when a release note or handoff needs the selected profile, delivery mode, score, policy value, directive list, rollout rows, warnings, and errors.

Interpreting Results:

Read blocker rows before the score. A default strict nonce draft can show Strict rollout, 13 directives, and 94/100, while still requiring a real per-response nonce and a reporting endpoint before enforcement. A high score means the entered policy shape is cleaner than a migration policy; it does not prove that the server can issue nonces, that hashes match deployed script bytes, or that every route was tested.

Visible Cue Best Reading Follow-up Check
Fix source expressions The policy contains invalid source tokens or an invalid reporting endpoint. Correct the listed field before copying Header Set.
no reporting badge The header lacks a violation-report destination. Add an HTTPS collector before relying on report-only evidence.
High risk posture 'unsafe-eval' or broad inline script permission remains in script-src. Remove eval-like runtime paths, add nonces or hashes, or keep the policy in migration review.
Review posture A source list, compatibility directive, or broad resource rule needs a release justification. Compare browser violation samples against the directive and narrow sources where possible.
Enforced strict CSP The selected header will block matching violations. Confirm report-only evidence, route coverage, fresh nonce or hash handling, and rollback steps before deployment.

The Directive Ledger is the best place to audit what the browser will see. The summary label is useful for a quick read, but source values such as https:, *, blob:, data:, broad frame rules, and compatibility reporting choices need a separate look before the header is enforced.

Technical Details:

A CSP header is a serialized policy value. Each directive starts with a directive name, followed by zero or more values, and directives are separated with semicolons. The generator writes a Reporting-Endpoints header only when a valid HTTPS reporting endpoint is entered, then writes either Content-Security-Policy-Report-Only or Content-Security-Policy with the generated policy value.

Rule Core

The source fields accept CSP source expressions separated by spaces, commas, tabs, or line breaks. Common CSP keywords are normalized into quoted form, duplicate tokens are removed, and invalid source tokens raise a visible error. Optional fetch directives are omitted when their fields are blank, while core document and navigation directives are generated from their own fields.

Rule Area Generated Behavior Review Signal
Script trust Nonce and hash modes emit script-src with 'strict-dynamic' plus the entered nonce or hash sources. Allowlist mode emits the explicit script source list. 'unsafe-inline' without nonce or hash control and 'unsafe-eval' become high-risk rollout items.
Baseline locks object-src, base-uri, form-action, and frame-ancestors are generated from dedicated fields. Non-'none' object, base, or embedding values are surfaced for review when they weaken a strict baseline.
Optional fetch directives font-src, worker-src, frame-src, media-src, and manifest-src are emitted only when values are present. Broad source expressions such as *, https:, plain HTTP, and wildcard hosts are marked for narrowing.
Reporting A valid HTTPS endpoint adds Reporting-Endpoints, a report-to directive, and optionally report-uri for older collectors. A missing endpoint adds a rollout item before moving from report-only collection to enforcement.
Advanced hardening Inline event handler blocking, inline style attribute blocking, Trusted Types directives, and HTTPS upgrade behavior are added when their switches are enabled. Trusted Types should be enabled only after compatible policies and DOM sink usage have been checked.

Score and Summary Logic

The score is a drafting confidence signal. Errors carry the largest penalty, warnings reduce confidence, report-only mode subtracts a small amount, strict nonce or hash authorization adds confidence, and any high-risk posture lowers the result.

score = clamp ( 100 - 30 ⁢ errors - 8 ⁢ warnings - reportOnlyPenalty + strictScriptBonus - highRiskPenalty , 0 , 100 )

The score is clamped between 0 and 100. Each input error subtracts 30, each warning subtracts 8, report-only delivery subtracts 4, strict nonce or hash script authorization with 'strict-dynamic' adds 6, and any High risk directive posture subtracts 18.

Summary Label Typical Trigger How to Read It
Input blocked One or more source-expression or reporting endpoint errors are present. Fix the listed field before copying the header.
Migration CSP The score drops below 60, often because legacy script allowances or broad sources remain. Use the header for observation and cleanup planning, not immediate enforcement.
Allowlist CSP The allowlist script model is selected and no blocking errors are present. Confirm that each host and scheme source is intentional.
Strict rollout Nonce or hash script authorization with 'strict-dynamic' is used in report-only mode. Replace placeholders, collect reports, and test core journeys before enforcement.
Enforced strict CSP Nonce or hash script authorization is used with enforced delivery and no input errors. Verify prior report-only evidence and rollout readiness because violations will be blocked.

The generated report-uri directive is compatibility output. CSP Level 3 favors report-to with Reporting API endpoint configuration, while older reporting collectors may still depend on report-uri. Emitting both can help during migration when the reporting endpoint is HTTPS and the receiving collector is ready.

Limitations and Privacy Notes:

The generated output is a draft header, not a live audit of a deployed site. The generator cannot verify server nonce generation, exact inline script hash bytes, browser coverage, third-party behavior, route coverage, or whether a reporting collector actually receives violation reports.

  • The header text, directive ledger, rollout queue, and JSON are assembled in the browser from the visible fields.
  • A reporting endpoint entered in the form is written into the draft header, but the generator does not contact that endpoint.
  • Enforced CSP can break pages immediately, so report-only evidence and route testing should come before deployment.

Worked Examples:

Strict nonce rollout for a new dashboard

A server-rendered dashboard starts with Strict nonce rollout, report-only delivery, Nonce placeholder set to {RANDOM_NONCE}, Default source set to 'self', and Image sources set to 'self' data: https:. The summary can show Strict rollout, 13 directives, and 94/100. The important Rollout Queue rows are Replace nonce placeholder per response and Add violation reporting, because the header is still not ready for blocking mode.

Legacy migration with broad script permissions

A legacy migration profile keeps allowlist script sources with 'unsafe-inline', 'unsafe-eval', and scheme-wide sources while old inline handlers are removed. The summary can fall to Migration CSP around 46/100, with High risk posture on script-src. Treat Rollout Queue as remediation work: remove eval-like paths, replace inline script allowance, add reporting, and keep the policy in report-only mode until those rows are addressed.

Reporting endpoint added before enforcement

A release candidate changes Header delivery to enforced and sets Reporting endpoint to a valid HTTPS collector URL. Header Set adds a Reporting-Endpoints line plus the CSP header, and the policy value can include both report-to and report-uri when the legacy reporting switch stays on. With the default strict nonce fields, the summary can show Enforced strict CSP and 100/100, but Rollout Queue still requires nonce replacement and critical journey testing.

Troubleshooting a bad source value

A pasted Script sources value contains a semicolon inside a token, or Reporting endpoint uses http://. Fix source expressions appears with a field-specific error, and Rollout Queue adds a blocker to correct the input. Remove the invalid token or change the endpoint to HTTPS before copying Header Set.

FAQ:

Should I start with nonce mode or hash mode?

Use nonce mode when the server can generate a fresh unpredictable nonce for every HTML response and add it to trusted script tags. Use hash mode when inline script bytes are stable enough to hash exactly and update whenever the deployed script changes.

Can I enforce the generated header right away?

Only after blocker rows are gone and the same policy has been tested in report-only mode or a staged environment. Enforced delivery blocks violations, so untested pages can break.

Why does the reporting endpoint require HTTPS?

The reporting field accepts only HTTPS URLs. When the value is valid, Header Set can include Reporting-Endpoints, report-to, and optional report-uri compatibility output.

Why is 'unsafe-eval' treated as high risk?

'unsafe-eval' allows dynamic JavaScript evaluation. The rollout queue flags it so libraries, framework settings, or legacy runtime paths can be reviewed before enforcement.

What does Trusted Types add?

Require Trusted Types adds Trusted Types directives for browsers that support them. Enable it only after the application has compatible policies and DOM sink usage, because unsupported code paths can break.

Does the generator contact my reporting endpoint?

No. The endpoint is included in the draft header text and JSON, but the generator does not send a test report or validate that the collector is reachable.

Glossary:

Content Security Policy
A browser policy that restricts which resources and document actions are allowed for a response.
Directive
A named CSP rule such as script-src, form-action, or frame-ancestors.
Source expression
A CSP token that names an allowed source, keyword, scheme, host, nonce, or hash.
Nonce
A fresh per-response value used to authorize trusted script tags.
Hash source
A CSP source expression that authorizes exact inline script bytes by cryptographic hash.
Report-only
A CSP delivery mode that records violations without blocking matching behavior.
Strict-dynamic
A script policy keyword that extends nonce or hash trust to scripts loaded by an already trusted script.
Trusted Types
A browser security feature that limits unsafe string use in certain DOM script sinks when required by policy.

References: