reviewing-content-security-policy

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 coordinate. If you can't name the authorization, stop.

The loop

1. Map the policy, its delivery, and the sinks it must protect. Read the policy and how it is delivered, and find whether the pages it covers have an injection sink: a place user input reaches markup or script. The presence or absence of that sink decides whether a weakness is exploitable or only defense-in-depth, so establish it first.

2. Check inline script. A script source that allows inline script with no nonce or hash lets an injected inline script or event-handler attribute run. This is the single most common real weakness, but read it carefully: a nonce or hash present alongside the inline allowance makes a modern browser ignore the allowance, so that combination is mitigated, not broken.