For payment pages
CSP reporting and PCI DSS 4.0
Requirements 6.4.3 and 11.6.1 put the JavaScript on your payment pages under scrutiny. A Content-Security-Policy with reporting is the browser-native way to see what is actually running there. This page explains what HeaderHawk produces, where that evidence comes from, and where it stops.
What this page is not claiming
HeaderHawk is a monitoring tool. Using it does not make anyone PCI DSS compliant, it is not a QSA-approved control, and no single tool satisfies 6.4.3 or 11.6.1 on its own. What follows is a description of what the product produces so you can decide how it fits your assessment. The summaries of the requirements are our paraphrase — read the standard itself, and talk to your assessor.
What the two requirements ask for
Both became mandatory on 31 March 2025, and both apply to pages that take payment card data — including a page that only embeds a payment iframe.
6.4.3
Manage the scripts on payment pages
- Every script loaded and executed on a payment page is authorized.
- The integrity of every script is assured.
- An inventory of all scripts is maintained, with a written justification for why each one is necessary.
11.6.1
Detect and alert on change
- A mechanism detects unauthorized modification to the payment page's security-impacting HTTP headers and script contents.
- It alerts personnel when a change is detected.
- It runs at least weekly, or at the frequency your targeted risk analysis defines.
6.4.3
Building the inventory
Most teams discover that the hard part of 6.4.3 is not writing the justifications. It is finding out what is on the page in the first place — the tag manager that loads three more tags, the vendor script that pulls a second script from a different origin, the thing marketing added in 2019. A reporting CSP answers that from the browser, which is the only place with the complete picture.
HeaderHawk collects two different signals, and they are good at different things.
1. What your policy would block — every browser
Put a tight script-src on your payment page in Content-Security-Policy-Report-Only mode. Nothing breaks, and every script that is not on the allowlist reports itself: the blocked URL, the page it ran on, the directive it violated, and — where the browser supplies them — the source file, line, and column it was reached from. HeaderHawk groups those by signature, so a thousand hits from one script are one row with a count and first- and last-seen timestamps. This is the reliable half — it works in every browser that supports CSP reporting, and it enumerates exactly what your allowlist does not yet cover.
2. What actually loaded, and its hash — Chromium
Add the 'report-sha256' keyword to script-src and Chromium sends an integrity hash each time it fetches and executes a script. HeaderHawk's Scripts view lists these by origin, by script URL with its hash, and by the page they ran on. Where violation reports tell you what a policy would stop, hash reports tell you what genuinely ran. Read the setup notes before you rely on it — the header combination is easy to get subtly wrong.
The authorization half of 6.4.3 is your allowlist. A script-src directive is a machine-readable, browser-enforced statement of which scripts you have approved, and HeaderHawk stores the policy that was in force alongside every report it receives. It does not author that policy for you, and it holds no field for the written business justification the requirement asks for. That stays in your documents.
Limits worth knowing before you rely on this
These are the same caveats the dashboard and the docs carry. They matter more here than anywhere else on this site, because an inventory you believe is complete and is not is worse than no inventory at all.
- Hash reporting is Chromium-only today
- Chromium 133+ implements 'report-sha256'. WebKit support is in progress and Firefox does not implement it. The feature is also new enough that behaviour varies between builds — our own testing has met Chromium versions that accept the keyword and emit no hash reports at all — so confirm what your visitors' browsers actually do before building a control on it. Coverage is partial by construction.
- Cached scripts produce no hash
- A browser generates a hash when it fetches and executes a script. A script served from cache is never fetched, so a well-cached page reports far fewer hashes than it has scripts, and returning visitors contribute almost none.
- Repeat sightings are sampled
- The first time a site reports a given hash it skips sampling; after that, repeat reports are sampled — 10% by default, adjustable per site — so counts are a sample, not a census. That first-sighting pass is a priority, not a guarantee: a site over its monthly quota or its daily hash ceiling can still have a new hash held back until the next sighting.
- Inline scripts are not subresources
- Hash reports describe scripts the browser fetched. A script written inline in the page is not a fetch and does not appear in the Scripts view. Report-only violations still surface it, with a snippet of its content when your policy includes 'report-sample'.
- The Scripts view starts on Team
- Hash reporting is a paid feature. On the free plan there is no Scripts section in the dashboard at all, so the inventory described above starts at Team, and the per-page breakdown at Professional. Report-only violation reporting — the broader of the two signals — is on every plan, free included.
- Nothing is scanned on a schedule
- Every row comes from a real browser loading a real page. A payment page with no traffic in a given week produces no reports that week, however the page is configured.
Taken together: treat the Scripts view as a sample of what runs on your pages rather than a complete census, and lean on report-only violations as the broader of the two signals. Neither replaces knowing what you deployed.
11.6.1
Detecting change
11.6.1 has two halves: script contents, and the page's security-impacting HTTP headers. HeaderHawk addresses part of the first half. It does not address the second at all — see below.
A new script appears
A script that is not on your allowlist produces violation reports the moment a real browser loads the page. HeaderHawk groups reports by signature into 15-minute windows and scores each window's confidence. The primary signal is browser diversity: when two or more browser families report the same violation it is almost certainly real, as is a single family reporting it twenty or more times. Those counts are of signal reports: violations HeaderHawk classifies as browser-extension noise are set aside first, and a window with nothing left after that raises nothing. Windows that clear the bar go out immediately to Slack, email, or a webhook. Quieter ones go into a daily or weekly digest instead, so a single stray report from one browser does not wake anyone. Windows are evaluated every minute, which is well inside 11.6.1's weekly floor — but the mechanism is passive, and it sees a change when a browser loads the page, not on a schedule you set.
An existing script's contents change
Change one byte of a script and its hash changes. A hash your site has not reported before skips the sample rate, so the new version shows up in the Scripts view as a second hash against a URL you already know — the shape you would expect from a vendor silently shipping an update. That surfaces in the dashboard; it does not raise an alert of its own, and it inherits every limit in the section above, including the ones about caching and browser support.
Read that first-sighting pass as a priority rather than a promise. It is still subject to your monthly report quota and to a daily per-site ceiling on hash events, and a site that hits either can have a new hash held over. Nothing is lost permanently — a hash that was not recorded stays new, and is taken the next time a browser reports it — but the change surfaces later than the page load that first carried it. If a control has to catch a script change inside a defined window, do not rest it on this alone.
How alerting is configured
Per site, you create rules that choose their channels, a deduplication window (24 hours by default, so a persistent problem alerts once rather than every quarter hour), and a digest frequency of daily, weekly, or none. There is no threshold to tune and no spike detection: alerts fire on the confidence rules described above and no others.
What you can put in front of an assessor
Grouped violations with counts and first- and last-seen timestamps, the individual reports behind each group, the policy that was in force when each one arrived, and — from Team upwards — the script inventory broken down by origin and by script, with the per-page breakdown on Professional and above. All of it is reviewed in the dashboard — there is no export or download today, so screenshots and a live walkthrough are what is available.
How far back that history goes depends on your plan. Report history is deleted at the end of the retention window:
| Plan | Report retention |
|---|---|
| Free | 15 days |
| Team | 30 days |
| Professional | 60 days |
| Business | 60 days |
Worth saying plainly: 11.6.1 asks for checks at least weekly, and the free plan's 15-day window holds barely two of them. It is enough to show the mechanism running, and thin if your assessor wants a longer trail. If evidence has to survive a quarterly or annual look, budget for a paid plan's window — or keep your own copy as you go. See pricing for what each plan includes.
What HeaderHawk does not do
Collected in one place, because you should not have to infer it from what we left out.
- It does not make anyone PCI DSS compliant, and it is not a QSA-approved or validated control. It produces evidence; your assessor decides what that evidence is worth.
- It does not monitor HTTP response headers. 11.6.1 covers headers as well as script contents, and nothing in HeaderHawk fetches your page or compares its headers over time. That half needs a separate control.
- It does not write, generate, or manage your CSP. You author the policy; HeaderHawk tells you where reality disagrees with it.
- It does not authorize scripts or store your written business justifications. It can tell you a script is new. It cannot tell you whether someone approved it.
- It has no configurable alert thresholds and no spike detection. Alerting works as described above and no other way.
- It offers no data export or download today. Evidence is reviewed in the dashboard.
See what is on your payment page
Add one header in report-only mode and find out. Nothing breaks, and reports start arriving with the next page load.