CSP Evaluator & Violation Report Parser
Audit your Content Security Policy for risky directives, parse browser violation reports, and generate stricter deployment-ready CSP snippets locally.
All CSP parsing, evaluation, and report translation happens locally in your browser. No policy text, violation reports, or any input is sent to CodeAva servers. This tool is safe for internal, draft, and sensitive policies.
All CSP parsing, evaluation, and violation report translation runs locally in your browser using JavaScript. Nothing you paste — policy headers, violation reports, or any input — is sent to CodeAva servers. This makes the tool safe for internal, unreleased, and sensitive policy configurations.
Why CSP is powerful but often misconfigured
Content Security Policy is one of the most effective browser-enforced defences against cross-site scripting (XSS) attacks. A well-configured CSP controls which scripts, styles, images, and other resources a page is allowed to load — and from where. When an attacker tries to inject a script, a strict CSP prevents the browser from executing it, even if the injection succeeds.
The catch is that a CSP that passes syntax validation can still be effectively useless for XSS defence. Policies with 'unsafe-inline' in script-src allow any inline script to execute — including injected ones. A wildcard * in script-src opens every domain on the internet as a valid script source. These patterns are syntactically valid but functionally equivalent to having no CSP at all for script control.
Teams also need visibility into what the policy is actually blocking in production. Browser CSP violation reports are the mechanism for this, but they arrive as dense JSON blobs that can be hard to interpret quickly — especially when mixing legacy report-uri format with the modern Reporting API. This tool handles both: evaluate the policy for risk, then translate violation reports into plain-English diagnostic cards with remediation guidance — all locally in the browser.
What this tool helps with
Best for
- Auditing a CSP header before deploymentpaste the policy value and get a risk score with specific risky directives flagged before the policy goes live.
- Debugging production CSP violationspaste raw violation report JSON from your reporting endpoint or browser console and get plain-English summaries with recommended fixes.
- Moving toward a stricter nonce-based CSPuse the Strict CSP alignment checklist to understand what gaps remain between your current policy and the nonce/hash + strict-dynamic model.
- Generating deployment-ready config snippetscopy platform-specific headers for Nginx, Apache, Next.js, Cloudflare, or Express after evaluating the policy.
- Security reviews and pen test prepquickly identify the highest-risk directives in a policy before a formal review, with detailed context for each issue.
- Fixing broken CSP rolloutsparse violation batches to understand what the policy is blocking in production, then decide whether to tighten or adjust specific directives.
Limitations to know
- Full application security auditingCSP evaluation covers header-level policy risk. Actual XSS exploitability depends on your application's input handling, DOM, and framework behavior — use a security scanner or pen test for a comprehensive assessment.
- Parsing non-JSON violation formatsthis tool expects standard JSON-structured violation reports as sent by browsers to report-uri or Reporting API endpoints. Raw server logs, custom formats, or non-JSON output require pre-processing.
- Nonce injection via static configthe snippet generator produces header config, but nonces must be generated per HTTP response on the server. A static nonce value in a config file defeats the purpose of nonce-based CSP.
How to use the CSP Evaluator
- 1
Choose your mode
Select CSP Header Evaluator to analyze a policy, or Violation Report Parser to translate browser reports.
- 2
Paste the CSP value or report JSON
For the evaluator, paste only the header value (not the header name). For the parser, paste one or more violation report objects as JSON — arrays are supported. Use the example buttons to load sample data.
- 3
Review the risk score and issues
The Issues tab groups findings by severity: Critical findings (like unsafe-inline without nonce/hash) should be fixed before deployment. Expand each finding for a detailed explanation and specific remediation guidance.
- 4
Check strict CSP alignment
The Strict CSP tab compares your policy against the nonce/hash + strict-dynamic model. Each checklist item links to what is missing and why it matters.
- 5
Copy a deployment snippet
The Snippets tab provides config for your deployment target. Fix critical issues first, then copy and deploy. Remember: nonces must be generated server-side per request — a static snippet alone cannot power a safe nonce-based CSP.
Common CSP issues and fixes
unsafe-inline is present in script-src
Remove 'unsafe-inline'. Add a server-generated nonce to every <script> tag and include 'nonce-{value}' in script-src, or precompute SHA-256/SHA-384 hashes of known inline scripts. Add 'strict-dynamic' so nonce-trusted scripts can load dependencies dynamically without needing to allowlist their domains.
unsafe-eval is present in script-src
Remove 'unsafe-eval'. Audit your codebase for eval(), new Function(), and string-based setTimeout/setInterval. Refactor to use explicit function references. Check third-party libraries — some template engines and older analytics SDKs use eval. Consider alternatives that do not require it.
script-src uses a wildcard (*)
Replace the wildcard with an explicit list of trusted origins, or adopt a nonce/hash + 'strict-dynamic' model to remove the need for domain allowlists entirely. A wildcard in script-src means any domain can serve executable scripts on your page.
object-src is missing or not set to 'none'
Add object-src 'none' to your policy. Without it, <object>, <embed>, and <applet> elements can load plugins that may bypass script-src restrictions. Even if you have no plugins, this directive should be explicitly closed.
base-uri is not restricted
Add base-uri 'none' or base-uri 'self'. An unrestricted base-uri allows an injected <base> tag to change the base URL for all relative links and form targets — a known bypass technique for nonce-based policies.
Violation reports are hard to read or normalize
Paste the raw JSON into the Violation Report Parser tab. The tool normalizes both legacy report-uri format (with a csp-report key) and modern Reporting API format (with a type and body key) into plain-English cards with blocked URL, directive, likely cause, and recommended next steps.
Policy is breaking scripts in production after tightening
Deploy the policy in Content-Security-Policy-Report-Only mode first. This reports violations without blocking anything, giving you visibility into what the policy would block. Use the Report Parser to process the incoming reports and identify which scripts need nonces, hashes, or narrowly scoped allowlist entries before switching to enforcement mode.
No reporting endpoint is configured
Add a Reporting-Endpoints header pointing to an endpoint you control (or a managed service like Report URI), then add report-to default to your CSP. For legacy browsers, also include report-uri. Without reporting, all violations are silently swallowed — you have no visibility into blocked resources or injection attempts.
Frequently asked questions
Related tools
What is a strict nonce-based CSP and why is it better than a domain allowlist?
A strict nonce-based CSP allows scripts to execute only if they carry a valid per-request cryptographic nonce or match a precomputed hash. The nonce is generated on the server for every HTTP response and added both to the script-src directive and to each authorized <script> tag. An attacker who injects a script cannot know the nonce and therefore cannot make it execute — even if the injection reaches the HTML.
A domain allowlist, by contrast, trusts any script served from the listed domain. If an attacker can host content on a trusted domain — for example, a CDN with open upload endpoints, a shared hosting environment, or an endpoint with a reflected XSS — the allowlist permits that script to run. Nonce-based policies close this gap by tying execution to code you explicitly authorized, not merely where it came from.
This is not a perfect guarantee — implementation matters. The nonce must be unique per response (never static), generated with a cryptographically secure random source, and injected server-side. Inline event handlers should be moved to nonce-attributed scripts. 'strict-dynamic' should be included so scripts loaded dynamically by nonce-trusted scripts are also permitted without needing to allowlist their sources.
CSP risk level cheat sheet
A practical reference for the most impactful CSP patterns and their security implications.
| Pattern / Directive | Risk level | Why it matters | Preferred fix |
|---|---|---|---|
| 'unsafe-inline' in script-src | Critical | Permits any inline script to execute, including injected ones — the primary XSS vector CSP is designed to block | Remove it; use nonces or hashes on script tags instead |
| 'unsafe-eval' in script-src | Critical | Allows eval() and new Function() — frequently exploited in XSS attacks and almost always avoidable | Refactor to avoid eval; audit third-party libraries |
| * wildcard in script-src | Critical | Any domain on the internet can serve executable scripts on your page — equivalent to no script policy | Replace with explicit origins or adopt nonce/hash + strict-dynamic |
| Broad third-party allowlist | High Risk | Trusted domains may host attacker-controlled content; each extra domain extends your attack surface | Minimize allowlisted domains; prefer nonce/hash model |
| Missing object-src 'none' | High Risk | Plugins loaded via <object>/<embed> can bypass script-src restrictions | Add object-src 'none' — always correct unless you use plugins |
| Missing base-uri restriction | Warning | Injected <base> tag can redirect relative links and form targets, bypassing nonce-based policies | Add base-uri 'none' or 'self' |
| Nonce/hash + 'strict-dynamic' + narrow policy | Strong | Ties script execution to code you explicitly authorized; withstands most allowlist-bypass techniques | Implement server-side per-request nonce generation |
CSP reporting: report-uri, report-to, and Report-Only mode
report-uri is the original CSP violation reporting mechanism, introduced in CSP Level 1. It instructs the browser to POST a JSON violation report to the specified URL when a policy violation occurs. Many existing deployments still use it, but it is deprecated in CSP Level 3 and being phased out in favour of the Reporting API.
report-to is the modern directive, used in conjunction with a Reporting-Endpoints HTTP response header that names endpoint URLs. The Reporting API provides a more structured, batched reporting mechanism that also supports other report types (deprecation warnings, network errors, etc.) through the same infrastructure. During migration, include both directives to catch violations in all browser versions.
Content-Security-Policy-Report-Only deploys the policy in observation mode: violations are reported to the reporting endpoint but resources are not actually blocked. This is the correct approach for rolling out a new or tightened policy without risking application breakage — observe, fix, then switch to enforcement. Report-Only provides no actual XSS protection until the policy is promoted to Content-Security-Policy.
Deployment context: platforms and nonce generation
The Snippets tab in the tool generates ready-to-use configuration for common platforms. The important principle across all of them: for a nonce-based CSP to be safe, the nonce must be regenerated for every HTTP response on the server. A static nonce in a config file — or a nonce generated once at build time — is not a safe nonce. Any observer who sees one valid nonce can reuse it in an injected script.
Nginx and Apache serve the policy as a static header. For a nonce-based policy, the nonce must be generated in application middleware and injected into both the CSP header value and the HTML before the response is sent. Nginx ngx_http_sub_module or a Lua script can automate this at the proxy layer.
Next.js supports per-request CSP headers through middleware (middleware.ts), where a nonce is generated with crypto.randomUUID() or crypto.getRandomValues(), passed into the CSP header, and also forwarded to the layout via request headers so each <Script> component can pick it up. The Next.js documentation covers the recommended pattern for this.
Cloudflare Workers can intercept the response and rewrite headers, including generating a per-request nonce and injecting it into both the CSP header and the HTML stream using the HTMLRewriter API.