Sandbox

A real iframe enforcing the CSP you write, with every violation piped back into the console mirror. Pick a scenario from the catalog to load a preset, or paste your own header and payload.

How this works. The iframe document carries your CSP via <meta http-equiv>, plus a tiny reporter that forwards every SecurityPolicyViolationEvent into the console mirror below. Limitations of meta-CSP: frame-ancestors, sandbox, and report-to are header-only and won't fire here. Everything else does.

Scenario catalog

Ten paired CSP + payload demos. Each loads its own header into the editor and re-renders the iframe. Watch the console for violations and compare against the "expected" line.

Expected: Browser blocks the inline <script> because it carries no nonce. CSP violation reported. Page renders, payload string never appended.

Lesson: A correct nonce policy makes injected inline scripts useless without the per-request token. This is the reference shape.

standards: NIST SP 800-53 SI-10 · OWASP ASVS V14.4

Live sandbox

iframe — meta-CSP enforced

violations & errors (0)

No events yet. Re-run or load a scenario.

Editor

Edit the policy or the payload, then hit Re-run to reload the iframe above.

Content-Security-Policy headerHTML payload (rendered in the sandbox iframe)

Static analysis (2)

Same 12-rule grader as the analyzer page, run live against the policy in the editor.

lowCSP11 — No CSP reporting configured

Without report-uri or report-to, CSP violations happen silently. You won't see in-the-wild XSS attempts or accidental policy breakage.

fix: Add a report-to endpoint (modern) or report-uri (legacy). Even logging to your own server is a huge upgrade.

infoCSP12 — upgrade-insecure-requests not set

Optional. If your app may load from a mix of http:// and https:// origins, this directive auto-upgrades requests, blocking mixed content.

fix: Add upgrade-insecure-requests if you serve over HTTPS and may have legacy http:// references.