Developer Utility

Free Content Security Policy Generator & CSP Scanner

Script Sentinel is a free Content Security Policy (CSP) generator and Chrome-based CSP scanner, including a Content Security Policy header generator. Enter a public URL with no account required to observe selected pages in Chrome and build an editable CSP header candidate from 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
Policy Editor

Waiting for scan

Idle
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

Content Security Policy can reduce XSS and injection risk by limiting what a browser may load or execute. A CSP scanner can turn observed browser activity into a useful starting policy, but a bounded scan cannot exercise every application flow. Review the result and test it 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

  1. Observe selected pages: Headless Chrome loads the requested public pages, records browser resource activity, and performs a bounded scroll-and-settle cycle.
  2. 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.
  3. 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.

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.

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.

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:

  1. Browser evidence: Load selected pages in headless Chrome and record resource activity after page load and a bounded scroll-and-settle cycle.
  2. Mixed-content review: Flag observed HTTP resources requested by HTTPS pages.
  3. Optional inline hashes: Add SHA-256 sources when Include SHA-256 hashes is selected. Re-scan whenever inline content changes.

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.

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.