How to debug Content Security Policy script-src errors

Start with the browser violation

A CSP console message normally identifies the blocked resource, the violated or effective directive, and part of the active policy. Copy the complete message. A shortened screenshot can hide the source expression or fallback that explains the block.

Then inspect the final document response in browser developer tools. A policy can be delivered by an HTTP header or, with limitations, a meta element. Multiple policies are enforced together, so editing one policy may not remove a restriction imposed by another.

Identify the effective script directive

script-src controls JavaScript sources. script-src-elem can override it for script elements, while script-src-attr controls inline event-handler attributes. When a more specific directive is absent, the browser falls back to script-src, then to default-src when script-src is also absent.

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com

With this policy, a script from another origin is blocked unless another applicable policy source permits it. The browser’s effective-directive field helps determine whether to inspect script-src, a more specific script directive or the default-src fallback.

Use the CSP Debugger

1. Open the CSP Debugger.
2. Paste the active Content-Security-Policy value.
3. Paste the complete browser CSP error when available.
4. Review the parsed directives, blocked resource and effective directive.
5. Compare the suggested source with the resource you actually intend to trust.

The debugger runs this analysis locally in the browser. It parses the supplied text and highlights likely fixes; it does not execute your application or replace browser testing.

Choose the narrowest appropriate fix

For an expected external script, add only the required scheme and host to the applicable directive. Confirm whether subdomains, ports or redirects are involved. Avoid broad defaults such as * or https: unless the security review explicitly accepts every matching source.

For an expected inline script, prefer one of these approaches:

• Move the script to an allowed external file when practical.
• Generate a cryptographically random nonce for each response and apply the same nonce to the allowed script element.
• Use a stable hash source for a fixed inline block, updating the hash when the content changes.

Do not add 'unsafe-inline' as a reflexive fix. MDN describes it as allowing all inline scripts covered by that directive and recommends nonce or hash approaches instead.

Test before production

Use Content-Security-Policy-Report-Only or a staging environment to observe violations without unexpectedly breaking production. Exercise the page paths and user actions that load scripts dynamically. Confirm the final response header after CDN transformations, not only the origin configuration.

When the expected behavior is confirmed, deploy the enforcing policy and monitor new violations. Keep the source list focused so a future third-party compromise does not gain unnecessary script execution rights.

Common mistakes

• Editing script-src when script-src-elem, another policy, or a fallback is the effective restriction.
• Copying the blocked host without checking redirects or the exact scheme and port.
• Adding *, https: or 'unsafe-inline' to silence the error broadly.
• Reusing a static nonce across responses.
• Hashing a different script body from the one delivered to the browser.
• Testing only the origin header while a CDN adds another policy.

Limitations

Scopeva analyzes the text you provide. It cannot see runtime DOM mutations, browser extensions, framework-generated nonces, report endpoints or policies not included in the input. Browser developer tools and a controlled staging test remain the source of truth for actual enforcement.