reviewing-content-security-policylisted

# Reviewing a content security policy: whether it stops the injection or only looks strict A content security policy is a defense-in-depth control against injected script, and reviewing one is less about listing weak directives than about a single judgment: if an attacker gets markup onto this page, does the policy stop the script from running. That reframing matters both ways. A permissive policy on a page with a real injection vector turns a mitigated cross-site-scripting bug into an exploitable one, and is a genuine finding. The same permissive policy on a page with no injection sink is defense-in-depth worth hardening but not an exploit. And a policy that looks weak, an inline allowance sitting next to a nonce, is often not weak at all, because the browser ignores the legacy allowance when the nonce is present. You review it by reading the policy against the pages it protects and asking what an injected script could still do. ## When to use - A response sets a content security policy, in a header, a meta tag, or configuration. - You are already looking at a page that reflects or stores user input, or want to know whether one is protected. - You need to tell a policy that blocks injected script from one that only appears to. ## Scope check Review policies on applications you own or are authorized to assess, and demonstrate a bypass only against pages in scope. A confirmed policy bypass paired with an injection is a working cross-site script, so treat it as such and co