Developer Utility

Free Content Security Policy Generator & CSP Scanner

Script Sentinel is a free Content Security Policy (CSP) generator and Chrome-based CSP scanner. Enter a public URL with no account required, then review, edit, and copy the generated header. The Content Security Policy header generator uses the resources and inline-code evidence reached during the scan.

Observe browser-loaded resources Generate an editable CSP header Test report-only CSP before enforcement

Scan Config

Target

Site URL Crawl Depth

Simplify policy

Detect mixed content

Same-origin only

Include SHA-256 hashes

Free generator scans are capped at 3 pages. Paid plans unlock monitored scans up to 10 pages per run.

Policy Editor

Waiting for scan

Idle

Your generated policy will be editable here, with Copy CSP and Download as HTTP Header actions. Preview a generated header and its review.

Console

Awaiting Scan

script-sentinel://scan-evidence Idle

sentinel target --waiting sentinel options --pending sentinel run scan --ready

How to Generate and Test a Content Security Policy

The CSP header builder returns an editable policy alongside the resources that informed it. Review the sources in the Policy Editor, make your changes, then use Copy CSP or Download as HTTP Header to take the candidate into testing. A bounded scan cannot exercise every application flow: test representative states with Content-Security-Policy-Report-Only before enforcement.

Reference Playbook

Need a stable CSP reference while you work? Use the guide pages for copyable examples, report-only rollout notes, and deployment-specific header formats.

How the CSP Scanner Builds a Policy Candidate

Observe selected pages: Headless Chrome loads the requested public pages, records browser resource activity, and performs a bounded scroll-and-settle cycle.
Build a candidate: Observed resources are mapped to CSP directives, review-worthy values are highlighted, and optional SHA-256 sources can be added for inline content.
Review and test: Edit the candidate, remove sources you do not intend to trust, and exercise representative flows with report-only CSP before enforcement.

What a real bounded scan changed

The example below comes from a one-page Script Sentinel scan of a production server-rendered application. The hostname and paths are anonymized, but the evidence categories and generated policy shape are retained. The reached page loaded same-origin JavaScript, stylesheets, fonts, images, a web manifest, and a same-origin form action.

scripts → script-src https://app.example/static/app.js became same-origin script evidence.

styles → style-src /static/site.css and /static/fonts.css became same-origin style evidence.

fonts → font-src Observed self-hosted .woff2 files produced a same-origin font source.

images → img-src Icons and image requests produced a same-origin image source.

manifest → manifest-src The observed web app manifest produced an explicit same-origin manifest source.

form action → form-action The reached form destination remained visible for reviewer confirmation.

Generated Candidate

Evidence retained as observed

The raw candidate kept both 'self' and the exact observed origin so the reviewer could see what the scan recorded.

Content-Security-Policy: default-src 'none'; base-uri 'none'; frame-ancestors 'none'; form-action 'self' https://app.example; object-src 'none'; script-src 'self' https://app.example; style-src 'self' https://app.example; img-src 'self' https://app.example; font-src 'self' https://app.example; manifest-src 'self' https://app.example; upgrade-insecure-requests;

Reviewed Candidate

Redundant same-origin entries removed

Because 'self' already represents the same scheme, host, and port, a reviewer can remove the duplicate exact-origin tokens.

Content-Security-Policy: default-src 'none'; base-uri 'none'; object-src 'none'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; manifest-src 'self'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests;

This reached state did not produce connect-src or frame-src evidence. That means no matching activity was observed during this bounded run—not that the application can never need API, WebSocket, consent-gated, authenticated, lazy-loaded, or embedded resources. Those states still belong in report-only testing.

Why Browser Evidence Helps

Manually writing a CSP is error-prone. A single missing domain in your script-src can break your analytics, chat widgets, or payment gateways. Conversely, broad values such as unsafe-inline or * can substantially weaken the restrictions that the policy is meant to provide.

Common pitfalls include:

Maintenance Fatigue: SaaS tools change their CDNs frequently. A static manual policy becomes obsolete quickly, leading to console errors.
Syntax Errors: CSP syntax errors can cause a browser to ignore a directive or source expression, changing how the policy is enforced.
Blind Spots: It is difficult to manually track every third-party script loaded by marketing tags or other dependencies.

A browser scan records resource requests and DOM evidence from the pages and states it reaches. Use that evidence to build an allowlist candidate, then exercise authenticated, conditional, consent-gated, feature-flagged, lazy-loaded, and user-triggered flows during report-only testing. Read more about the scanner's methodology and limitations.

Using WordPress? The free WordPress CSP scanner and plugin can scan up to 10 reached public pages and keep activation, public-delivery verification, deactivation, and prior-state restore under explicit administrator control.

What to Review Before Enforcement

Once you have generated a candidate policy, review its sources and test it in report-only mode before enforcement. Script Sentinel supports that review by:

Browser evidence: Load selected pages in headless Chrome and record resource activity after page load and a bounded scroll-and-settle cycle.
Mixed-content review: Flag observed HTTP resources requested by HTTPS pages.
Optional inline hashes: Add SHA-256 sources when Include SHA-256 hashes is selected. Re-scan whenever inline content changes. For one inline block, use the CSP hash generator.

When `strict-dynamic` and Nonces Fit

strict-dynamic can propagate trust from a nonce- or hash-authorized root script to scripts that it loads. It can help some loader-based applications, but it changes how supporting browsers interpret host allowlists and requires deliberate integration.

A nonce must be unpredictable, generated for each response, and applied to both the CSP and the intended script elements. Script Sentinel does not create or inject per-response nonces. See MDN's strict-dynamic guidance for the browser semantics.

Read what a dynamic CSP generator does to choose between scan-based generation and application-managed policies. To start a scan from your browser toolbar, see the CSP generator extension guide.

The generator produces an observed-behavior candidate. Complex applications usually need manual source review, representative user-flow testing, and report-only validation. If you need help interpreting the output or planning a rollout, contact Script Sentinel support.