By problem
Solutions
Five problems people arrive with, and what a Content Security Policy with reporting actually does about each one. Every page follows the same order: what the attack is, what the browser reports when it happens, what HeaderHawk does with that report, and where CSP alone is not enough.
What these pages are not claiming
HeaderHawk receives violation reports. It is not in your visitors' request path, it does not run on your pages, and it blocks nothing — when something is blocked, it is your own policy header doing it, in the visitor's browser. Report-only mode, which is where every rollout starts, blocks nothing at all by design. Read each page as a description of what becomes visible, not of what becomes impossible.
Cross-site scripting
What a script-src violation report contains when a page refuses an injected script, how inline violations group by code sample, and why CSP is a second line of defence rather than an XSS fix.
Magecart skimming
What a report shows when a skimmer exfiltrates card data from a payment page, and why a script allowlist misses a modified first-party file.
Third-party scripts
What a report shows when a vendor's script loads a host you never approved, how the source-file field identifies which tag did it, and what reporting cannot tell you about code you already allow.
Clickjacking
What a frame-ancestors report contains when someone frames your page, why it points the opposite way from every other directive, and why it supersedes X-Frame-Options.
Mixed content
What a report shows when an https page loads an http subresource, why the browser's own mixed-content blocking never reports, and why this is usually the first thing a new policy finds.
Working to a requirement instead?
PCI DSS 4.0 takes the same approach from the other end: it starts with requirements 6.4.3 and 11.6.1 and maps what HeaderHawk produces onto them, including the halves of those requirements nothing here covers.