Treating a Later Duplicate as an Override
Within one policy, the first directive name wins and later duplicates are ignored. Fix the header producer instead of trusting the final-looking value.
CSP Header Analyzer | Review Effective Policy Directives
SecurityRuns in Your Browser (No Uploads)
Paste one Content-Security-Policy field or policy value to inspect comma-separated policies, effective first directives, source expressions, Report-Only disposition, and context-aware review findings. The local report preserves unknown and duplicate directives, distinguishes enforced from report-only evidence, and explains fallback behavior without fetching a page, executing a policy, or treating parser findings as proof that an application is secure.
What to do next
Continue with a related workflow or open the next tool that usually follows this task.
Workflow guide
Analyze a Content-Security-Policy header before deployment
Use this workflow when a CSP blocks an expected resource, a candidate policy produces noisy reports, or a proxy changes the header you intended to ship. It combines local policy parsing with browser violation evidence and a final deployed-edge check, without treating static findings as a security certificate.
OpenRelated toolHash Generator and File Checksum | SHA-256 and MD5
Hash UTF-8 text or exact file bytes and compare a full checksum locally.
OpenRelated toolHTTP Header Parser for Request and Response Debugging
Parse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
OpenRelated toolIDN Converter for Unicode and Punycode Domains
Convert one IDN between Unicode and Punycode with strict validation and label review.
OpenHow to Use This Tool
Copy one exact Content-Security-Policy or Content-Security-Policy-Report-Only field from the deployed response. A bare policy value also works, but its enforcement disposition will be unknown.
Remove cookies, authorization values, signed reporting URLs, and unrelated headers before pasting. Use Security Headers Checker for a complete response capture.
Run the analyzer and confirm the header disposition, policy count, recognized directives, unknown directives, and source-expression count.
Review duplicate directives per policy. Browsers use the first directive with a given name in that policy, so a later duplicate does not replace it.
Resolve high-risk findings in enforced policies first, then inspect Report-Only warnings, legacy directives, mixed 'none', invalid sources, and fallback behavior.
Copy or download the normalized review, test the real page behavior and violation reports, and verify the deployed header again after CDN or proxy changes.
When to Use This Tool
Compare Enforced and Report-Only Rollouts
Confirm whether a copied field blocks resources or only reports violations before promoting a candidate policy to enforcement.
Investigate Duplicate Directive Surprises
See which first directive remains effective when templates, middleware, a reverse proxy, or a CDN appends the same directive again.
Review Nonce and strict-dynamic Compatibility
Distinguish active unsafe-inline from backward-compatible tokens that modern CSP processing ignores when nonce, hash, or strict-dynamic trust is present.
Trace Browser Violation Reports
Group fetch, document, navigation, and reporting directives before mapping a blocked script, API request, image, frame, or form submission.
Prepare a Repeatable Release Review
Normalize a bounded policy into a stable report for pull requests, incident notes, deployment checklists, and before-and-after comparisons.
Common Mistakes
Calling Every unsafe-inline Token Active
A nonce, hash, or strict-dynamic can override unsafe-inline for relevant modern CSP processing. Review compatibility behavior instead of counting the token alone.
Assuming Report-Only Protects the Page
Content-Security-Policy-Report-Only records violations but does not enforce blocking. The same source expression has a different operational consequence.
Reading Multiple Policies as Alternatives
Comma-separated or repeated enforced policies are applied together. A request must satisfy every enforced policy, so another policy cannot loosen an earlier one.
Editing Without Real Page Tests
Static review cannot know runtime nonces, hashes, redirects, injected markup, workers, browser support, or every route dependency. Test the deployed application and reports.
Examples
Review a nonce-based enforced policy
Use a real per-response nonce rather than copying this example nonce into production. The analyzer can read the token but cannot verify nonce generation or markup matching.
Input
Content-Security-Policy: default-src 'self'; script-src 'nonce-AbCd12_-' 'strict-dynamic'; style-src 'self'; img-src 'self' https: data:; connect-src 'self' https://api.example.com; object-src 'none'; base-uri 'none'; frame-ancestors 'none'; report-to csp-endpointOutput
Enforced policy with recognized fetch, document, navigation, and reporting directives. The img-src data: value is informational; no active high-risk script source is reported.Separate Report-Only from enforcement
The policy is useful for observing candidate violations, but it does not block the risky inline behavior shown in the field.
Input
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'unsafe-inline' https://cdn.example.com; report-uri https://reports.example.com/cspOutput
Report-Only disposition, active candidate unsafe-inline warning, deprecated report-uri compatibility note, and no enforced high-risk count.Find first-wins duplicates across two policies
A duplicate inside one policy is different from the same directive appearing in a second policy. The latter adds another restriction.
Input
Content-Security-Policy: default-src 'self'; script-src 'self'; script-src *, connect-src 'none'Output
Two cumulative enforced policies. Policy 1 keeps the first script-src 'self' and ignores the later wildcard duplicate; Policy 2 independently blocks connections.How the CSP Review Is Calculated
The parser follows CSP Level 3 serialized-policy structure: comma separates policies, semicolon separates directives, names are ASCII case-insensitive, and empty semicolon segments are ignored.
Each policy keeps the first occurrence of a directive name and reports later occurrences as ignored duplicates. The same directive in another policy is not a duplicate because policies apply cumulatively.
Unknown well-formed directive names remain visible instead of being silently deleted. This helps expose typos while avoiding a claim that an extension or future directive is universally unsupported.
Source checks are directive-aware. Wildcard, data:, blob:, plain HTTP, unsafe-eval, and unsafe-inline do not receive one universal severity across script, image, worker, object, and fallback contexts.
For relevant inline checks, nonce or hash sources make unsafe-inline ineffective; strict-dynamic also changes modern script processing. Compatibility warnings remain where older browsers may interpret fallback hosts or wildcards differently.
Input is bounded by UTF-8 bytes, lines, line size, policy count, directive count, and source count. The tool analyzes pasted text locally and does not fetch, execute, enforce, or certify the policy.
Frequently Asked Questions
Does this prove that my CSP is secure?
No. It parses and reviews one pasted field. It cannot model every browser version, runtime nonce, injected element, route dependency, server behavior, or application vulnerability.
Why is unsafe-inline sometimes marked ignored?
CSP inline matching does not allow all inline behavior when the same effective source list contains a valid nonce or hash. For scripts, strict-dynamic can also override unsafe-inline in modern processing.
Which duplicate CSP directive is effective?
Inside one serialized policy, the first directive with that name is used and later duplicates are ignored. Directives in separate policies still apply as separate cumulative restrictions.
Why does a bare policy value show unknown disposition?
Without the field name, the analyzer cannot know whether the value came from Content-Security-Policy or Content-Security-Policy-Report-Only. Paste the full field when enforcement matters.
Can I paste a complete curl response?
Use Security Headers Checker or HTTP Header Parser for a complete request or response capture. This focused analyzer accepts one CSP field or one bare serialized policy list.
Does missing default-src always mean the policy is unsafe?
No. default-src is a fetch fallback, not a universal requirement. The analyzer reports its absence as context so you can verify whether explicit directives cover the resource types your application uses.
Is the pasted policy sent anywhere?
The analysis and report are produced in the browser. Still remove signed report endpoints, internal hostnames, and other unnecessary secrets before pasting or sharing the exported report.
How This Tool Was Verified
Maintained and tested by SimpleWebUtilsReviewed
Method: For “Review a nonce-based policy without treating image data as script risk”, we entered the documented fixture in CSP Header Analyzer and followed “Reduce the capture before sharing” before “Interpret sources in their effective context”. We compared the browser result with the stated output, then reviewed “Capturing the origin instead of the edge” and “Editing a duplicate that is ignored” as separate failure boundaries.
Expected result: The parser kept the nonce and 'strict-dynamic' relationship intact, reported no high-risk finding, and treated img-src data: as an item to justify rather than a script-source failure.
Sources and standards
- Content Security Policy Level 3World Wide Web Consortium (W3C)
Related workflow guides
Use these focused guides when you need a practical workflow before opening the tool.
Workflow guide
Analyze a Content-Security-Policy header before deployment
Use this workflow when a CSP blocks an expected resource, a candidate policy produces noisy reports, or a proxy changes the header you intended to ship. It combines local policy parsing with browser violation evidence and a final deployed-edge check, without treating static findings as a security certificate.
Workflow guideCheck the final response security headers before launch
Use this workflow to turn a curl -I or DevTools capture into repeatable release evidence. It checks the final response locally, separates enforced CSP from Report-Only monitoring, preserves deployment context, and ends with live verification plus the application checks that response headers cannot cover.
Related Tools
Continue with another maintained workflow
Hash Generator and File Checksum | SHA-256 and MD5
Hash UTF-8 text or exact file bytes and compare a full checksum locally.
Encoding
HTTP Header Parser for Request and Response Debugging
Parse bounded HTTP header blocks locally with default secret masking and protocol diagnostics.
Encoding
IDN Converter for Unicode and Punycode Domains
Convert one IDN between Unicode and Punycode with strict validation and label review.
Encoding
Security Headers Checker | Final HTTP Response Review
Review the final pasted HTTP response for enforced and context-dependent security-header signals.
Security
URL Parser and Analyzer | Query Parameters and Relative URLs
Parse absolute URLs or resolve references with raw, decoded, normalized, and duplicate-query views.
Converter