2026-09-07 · 6 min read · Rahul Chitturi
- csp
- security
- debugging
A Content Security Policy can block a script, style, image, or connection even when the resource loads normally without the policy. The browser evaluates the delivered policy, redirect chain, element attributes, and final resource URL together.
Adding broad wildcards or unsafe-inline may hide the console error, but it also removes much of the protection the policy was meant to provide.
Find the effective directive
Capture all policy headers and meta policies, the browser violation message, blocked URL, disposition, document URL, and exact element. Multiple policies are enforced together, so a permissive new header does not override a restrictive old one.
- Follow directive fallbacks such as script-src to default-src
- Distinguish enforce and report-only policies
- Inspect the final URL after redirects
- Check browser extensions separately from application resources
Verify nonces and hashes as byte contracts
Generate an unpredictable nonce per HTML response, place the same encoded value in the policy and approved elements, and do not reuse it as a long-lived configuration value. Static inline content can instead use a policy hash over the exact supported bytes.
Whitespace and content changes alter a hash. Hash sources normally authorize inline blocks, not an arbitrary remote file merely because its downloaded bytes happen to match.
A Flashman workflow
Use the hash and Base64 tools with public inline fixtures, URL tool for source and redirect checks, diff for delivered policies, and HTML entities tool when template escaping changes visible markup. Keep real session HTML out of tickets.
Test fresh nonces, stale pages, inline changes, dynamic imports, redirects, third-party resources, report-only rollout, cached HTML, error pages, and every supported browser.