reviewing-content-security-policy

name	reviewing-content-security-policy
description	Review a content security policy as a script-injection defense and judge whether it would actually stop injected script, with the discipline that a weak policy is a real finding mainly where an injection sink it would otherwise block exists. Covers a script source that allows inline script with no neutralizing nonce or hash, that allows arbitrary hosts or data URLs, or that trusts a host serving attacker-usable script; a nonce that is static, reused, low-entropy, or reflected from input; a missing base-uri or object-src that defeats an otherwise strong nonce policy; and a report-only header shipped as the only policy. Use when reviewing a policy in a response header, a meta tag, or config, alongside the pages it protects. The policy is the control under test, injected script is the sink it must block, and a gap the injection reaches is the bug.
license	MIT

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.