A CSP needs effective restrictions, not just a header name
Content Security Policy gives a browser rules for loading resources and performing certain actions. A useful policy can limit where scripts come from, stop unnecessary plugin content, restrict framing and reduce the impact of injected markup. A policy with broad sources or misunderstood fallbacks may provide much less protection than its presence suggests.
This auditor parses a policy value you paste and checks selected structural weaknesses. It preserves the first occurrence of duplicate directives, looks at effective script-source fallbacks and highlights several permissive choices. It does not load a target page, execute an attack or prove that a policy cannot be bypassed. The result is a configuration review to support careful implementation and browser testing.
Follow directive fallback rules
The default-src directive acts as a fallback for several fetch directives, but not for every CSP control. If script-src is absent, applicable script loading can fall back to default-src. A separate script-src-elem can govern script elements in modern CSP implementations. That means the policy must be read as a set of related directives rather than isolated keywords.
Some controls require explicit declarations. In particular, base-uri and frame-ancestors do not simply inherit default-src. A restrictive default policy should not be assumed to prevent a hostile base element or every unwanted embedding context. The auditor calls attention to these omissions so you can assess their relevance to the application.
Repeated directives inside one policy are another common source of confusion. Browsers use the first recognised occurrence rather than merging the values of later duplicates. If a configuration generator appends a second script-src, the new value may not do what its author expects. This tool reports duplicate directives and retains the first value in its parsed output.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Review script permissions with context
Sources such as a wildcard, a whole scheme like https:, or data: can greatly widen the set of scripts a page may execute. Whether a host allowlist is safe also depends on what those hosts serve. A domain that contains attacker-controlled uploads or JSONP endpoints can undermine a policy even when the allowlist appears short.
The unsafe-inline keyword needs particular care. Nonces, hashes and strict-dynamic can change how modern browsers interpret the script policy. This auditor flags its presence for review rather than pretending one substring fully determines enforcement. Inspect the complete policy and the browser versions you support, especially when maintaining compatibility with older clients.
Unsafe-eval is a different permission. It allows forms of string compilation such as eval that a normal restrictive script policy blocks. Removing it can expose dependencies on older libraries or development tooling. Test the production bundle and real workflows after a change; a policy that works on a simple landing page may break an editor, embedded widget or account flow.
Roll out restrictions with useful feedback
Before enforcing a stricter policy, inventory the resources and actions the application actually needs. Start with documented destinations and remove accidental dependencies where possible. For complex sites, a report-only policy can reveal violations without blocking them. That phase is an observation tool, not the final enforcement state.
Reports require a configured collection mechanism and careful handling because URLs and other contextual data can be sensitive. This auditor does not create a reporting endpoint or collect violations. It checks a pasted value. To see actual enforcement, use browser developer tools and controlled tests that exercise login, payment, forms, embedded content and error pages.
Check where the policy is delivered. Multiple policy headers can apply together, with the browser enforcing their combined restrictions rather than treating them as a simple replacement sequence. A meta-delivered policy also has limitations compared with an HTTP response header. This parser expects one policy value and cannot reconstruct the complete enforcement context from a copied fragment.
Keep a versioned copy of the deployed policy with the application release. When a dependency adds a new connection destination, review the reason before widening connect-src. Broadening a directive to a wildcard can hide the original compatibility issue and make later policy maintenance harder.
Patterns that deserve a closer look
| Pattern | Reason for review |
|---|---|
| Missing script-src and default-src | There may be no applicable restriction on script sources. |
| script-src 'unsafe-eval' | String compilation is permitted; check whether the application needs it. |
| Missing frame-ancestors | Embedding is not restricted by default-src fallback. |
| Duplicate directive | A later occurrence is not a reliable override. |
| 'none' mixed with other sources | The directive should be reviewed; none is intended to stand alone. |
Strengths and limitations
What this is useful for
The audit explains fallback behaviour, duplicate handling and selected risky permissions in a form you can inspect locally. It helps catch mistakes during configuration review before deployment. The parsed directive map makes it easier to compare what was pasted with what the checker evaluated.
What to keep in mind
Static checks cannot prove bypass resistance or application compatibility. The parser does not exhaustively validate CSP grammar, model every browser version or merge multiple delivered policies. Host trust, nonce generation, DOM injection and runtime behaviour require broader application review.
Common questions
Can I copy the example policy into production?
Use it as a starting point for understanding directives, not as an untested deployment prescription. Your application may need specific scripts, images, connections and framing behaviour. Build a policy from actual requirements, then test representative workflows and violation reports before enforcing it widely.
Does a report-only policy block injected scripts?
No. Report-only mode is intended to observe violations without applying the policy’s blocking behaviour. A strict-looking value delivered only in Content-Security-Policy-Report-Only is therefore not equivalent to an enforced Content-Security-Policy header. Make the deployment mode explicit during reviews.
Is the pasted policy uploaded?
No. Parsing and findings are produced in the browser tab. The auditor does not contact any hosts mentioned in the policy, execute its source expressions or send the configuration to a third-party scanner. Downloaded reports include the policy’s source names, so review them before sharing.
Why does the tool flag a policy that uses nonces?
Some flagged keywords can behave differently when combined with nonces, hashes or strict-dynamic. The finding is a prompt to inspect effective behaviour, not a claim that every such policy is broken. Check the whole directive, nonce lifecycle and supported browser versions before deciding whether the keyword is acceptable.