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
Export to PDF Fullscreen
Customize
Advanced
:

Content Security Policy, usually shortened to CSP, is a browser security control that tells a page which scripts, styles, images, frames, connections, forms, and legacy object surfaces are allowed. A well-planned policy can reduce the damage from cross-site scripting and unwanted embedding by limiting what a browser accepts. A rushed policy can also break real pages, especially when old templates, tag managers, payment pages, dashboards, and help widgets load resources from several places.

CSP header drafting is a planning step before server configuration. The useful question is not only which sources should be allowed, but how much confidence exists before blocking violations. Report-only delivery lets teams collect violation evidence without blocking users. Enforced delivery blocks matching violations, so the policy needs stronger proof across login, checkout, admin, embedded, and content-heavy routes.

CSP header assembly flow from rollout intent through trust model, directives, review notes, and header output

Strict CSP usually starts with script authorization through nonces or hashes, plus baseline directives such as object-src 'none', base-uri 'none', and frame-ancestors 'none'. Allowlist CSP can be useful during migration, but broad sources such as https:, wildcard hosts, 'unsafe-inline', and 'unsafe-eval' deserve review before enforcement.

A generated header is a draft, not proof that the site is hardened. The values still need server integration, fresh nonce generation when nonce mode is used, exact script hashes when hash mode is used, and browser testing against the routes that users actually visit.

Technical Details:

A CSP policy is a serialized list of directives separated by semicolons. Fetch directives such as script-src, style-src, img-src, connect-src, font-src, worker-src, and frame-src limit resource loading by type. Document and navigation directives such as base-uri, form-action, and frame-ancestors cover document behavior, form submission, and embedding permission.

Delivery mode changes browser behavior. Content-Security-Policy-Report-Only monitors violations and produces evidence without blocking matching loads. Content-Security-Policy enforces the policy and can stop scripts, frames, requests, or submissions that do not match the directive set. Report-only is safer for discovery; enforced mode needs stronger route coverage and rollback planning.

Rule Core

The generator combines a selected profile with source expressions, script authorization, optional reporting, and hardening toggles. Source expressions are split on spaces, commas, tabs, and line breaks, common CSP keywords are normalized into quoted form, duplicate tokens are removed, and invalid tokens raise a source-expression error before the header should be copied.

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 only 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 their own fields rather than relying on default-src. Non-'none' object, base, or embedding controls are surfaced for review when they weaken the selected baseline.
Optional fetch directives Font, worker, frame, media, and manifest directives are emitted only when their source fields contain values. Broad source expressions such as *, https:, and wildcard hosts are marked for narrowing after report evidence is collected.
Reporting A valid HTTPS reporting endpoint adds a Reporting-Endpoints header, 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 the application has compatible policies and DOM sink usage.

Score and Output 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 script authorization adds confidence, and any high-risk directive posture lowers the result.

score = clamp ( 100 - 30 ⁢ errors - 8 ⁢ warnings - reportOnlyPenalty + strictScriptBonus - highRiskPenalty , 0 , 100 )
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. The output is not ready for server use.
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 each host and scheme source is intentional, then trim broad entries after reports are reviewed.
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 changing to 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 collectors may still depend on report-uri. Emitting both can be practical during migration when the reporting endpoint is HTTPS and the receiving collector is ready.

Everyday Use & Decision Guide:

Start with Policy profile. Use Strict nonce rollout for server-rendered pages that can issue a fresh nonce on every response. Use Strict hash rollout for mostly static pages where exact inline script bytes can be hashed and kept in sync. Use Balanced web app, Static site, API documentation site, or Legacy migration audit when the source lists need a staged allowlist shape before stricter cleanup.

Leave Header delivery on report-only while discovering violations. Switch to enforced only after the Rollout Queue no longer contains blocker items and the same policy has been exercised against real user journeys. If a reporting endpoint is available, enter its HTTPS URL so the header set includes the reporting header and reporting directives.

  • For nonce mode, replace {RANDOM_NONCE} with a per-response nonce and mirror it on trusted script tags.
  • For hash mode, replace placeholder hashes with hashes for the exact inline script bytes after minification or templating.
  • For allowlist mode, keep Script sources, Connect sources, and frame-related sources narrow enough to explain in a release review.
  • Keep Object source, Base URI, and Frame ancestors tight unless legacy behavior or partner embedding is intentional.
  • Use the advanced switches for Block inline event handlers, Block inline style attributes, and Require Trusted Types only when the application is ready for those constraints.

The best first read is the top summary, then the warnings, then Directive Ledger. The ledger tells you each directive value and posture, which is where broad image, frame, media, script, and connection sources stand out. Rollout Queue is the action list for the release owner.

Do not treat a high score as a guarantee. A score can look strong while the server still fails to replace nonce placeholders, a static hash is stale, or an untested route loads a third-party script that report-only mode would have revealed. Copy the header only after the blocker rows and source-expression errors are gone.

Step-by-Step Guide:

Build one candidate policy for one rollout shape, then review the generated header, directive ledger, and queue before moving it to server configuration.

  1. Choose Policy profile. The summary should update from the selected baseline, such as strict nonce, strict hash, balanced app, static site, API documentation, or legacy migration.
  2. Set Header delivery to report-only for discovery or enforced for a policy that is ready to block violations. The Header Set tab changes the header name to match.
  3. Choose Script trust model. In nonce mode, fill Nonce placeholder; in hash mode, fill Script hashes; in allowlist mode, fill Script sources.
  4. Review the core source fields: Default source, Style sources, Image sources, Connect sources, Frame ancestors, Object source, Base URI, and Form action.
  5. Open Advanced when fonts, workers, child frames, media, manifests, reporting, inline attribute blocking, or Trusted Types need separate directives.
  6. Check Fix source expressions. If it appears, remove semicolons, control characters, or quotes inside source tokens, and make sure Reporting endpoint is a valid HTTPS URL.
  7. Open Directive Ledger and confirm the Posture and Deployment note for every directive before copying individual rows or CSV evidence.
  8. Open Rollout Queue. Clear blocker rows such as nonce replacement, hash replacement, invalid sources, missing reporting, 'unsafe-eval', or 'unsafe-inline' without nonce or hash control.
  9. Use Header Set for the final header text and JSON when a structured release handoff needs the policy value, score, directive list, warnings, and queue rows.

Interpreting Results:

The first blocker row matters more than the score. A default strict nonce draft can show Strict rollout, 13 directives, and 94/100, while still warning that no reporting endpoint is configured and that the nonce placeholder must be replaced per response.

Visible Cue Best Reading Follow-up Check
Fix source expressions The policy contains invalid source tokens or an invalid reporting endpoint. Correct the named field before using Header Set.
no reporting badge The generated header lacks a reporting destination. Add an HTTPS collector before relying on report-only evidence.
High risk script 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 directive posture A source list or compatibility choice should be justified before enforcement. Compare browser violation samples against the directive and narrow sources where possible.
Enforced strict CSP The header will block violations for the selected settings. Confirm report-only evidence, route coverage, and rollback steps before deployment.

A generated CSP cannot prove that the server will inject fresh nonces, that hashes match deployed script bytes, or that every browser path has the same header. Treat the output as a careful draft and verify the deployed response with browser violation logging before calling the rollout complete.

Worked Examples:

Strict nonce rollout for a new app

A new 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 rows are Replace nonce placeholder per response and Add violation reporting, because the header is still a draft until the server and collector are wired correctly.

Legacy migration that still permits risky script

A legacy profile uses allowlist script sources with 'unsafe-inline', 'unsafe-eval', and scheme-wide sources while the team removes old inline handlers. The generated summary can fall to Migration CSP around 46/100, with High risk posture on script-src. Rollout Queue should be read as remediation work, not as approval to enforce.

Reporting endpoint added before enforcement

A release candidate changes Header delivery to enforced and sets Reporting endpoint to https://csp.example.com/reports. Header Set adds a Reporting-Endpoints line plus report-to, and can also include report-uri when the legacy switch stays on. If warnings are gone, the summary can reach Enforced strict CSP, but the 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 a reporting endpoint uses http://. Fix source expressions appears with the field-specific error, and Rollout Queue adds a blocker to correct the input. Fix the 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 nonce for every HTML response and add it to trusted script tags. Use hash mode when inline script content is stable enough to hash exactly and update whenever bytes change.

Can I enforce the generated header right away?

Only after the 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, the header set can include the reporting header, 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.

Does the generator contact my reporting endpoint?

No. The header text and result tables are assembled in the browser from the visible fields. A reporting endpoint is written into the draft header, but it is not contacted by the generator.

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.

References: