HTTP security header monitoring for 11.6.1
A loosened Content-Security-Policy changes what the browser will permit and is invisible in the page body. Headers are named explicitly in 11.6.1 for that reason.
Start for free
Talk to an expert
What is header monitoring?
Header monitoring records the security-relevant HTTP headers your payment pages actually returned to real browsers, and alerts when a value changes. PCI DSS 11.6.1 names HTTP headers explicitly alongside page content, because weakening a header is a quiet way to enable an attack without touching anything visible. Removing X-Frame-Options makes clickjacking possible; loosening a CSP admits a new script origin. Neither shows up in the page body, and both are often the first observable step rather than the attack itself.
Distinct values, not just the current one
The useful weekly record is every distinct value observed per header. One value across the window means the header was stable. Two means something changed, and the record shows what it changed to and when, which is precisely the evidence 11.6.1 asks you to hold.
As received by the browser, not as intended
The requirement says as received by the consumer browser. Headers can be rewritten by a CDN, an edge worker, a reverse proxy or a misconfigured cache, so what your origin sets and what the customer got are not always the same thing. Recording the received value is the only version that answers the requirement.
Which headers matter
Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy carry most of the security meaning. All observed headers are recorded, and these are the ones that raise alerts by default.
Requirement 11.6.1 is a change-detection record. Two distinct values for one header inside the weekly window is the change, and the alert is the evidence that personnel were told.
Related platform capabilities
Script inventory
Every script, with a justification per script.
Tamper detection
Content and integrity changes on the page.
Vendors and load chains
Who loaded whom, and from where.
Script blocking
By URL, hash, domain, or single action.
Monitor-only mode
The same evidence, nothing stopped.
Alerts
Three channels: email, webhook, or S3.
Frequently asked questions
Read the FAQ
The security-relevant set by default: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-Content-Type-Options and Referrer-Policy. All observed headers are recorded, and you can add any header to the alerting set.
This is common with a nonce-based policy, and it is handled by comparing policy structure rather than the literal string, so a rotating nonce is not treated as a change. A new directive or a newly permitted origin is.
Yes, and this is a genuine advantage of recording what the browser received. If your origin sets a header and something in the path removes it, the received value is what gets recorded, so the gap is visible rather than assumed away.
No. The requirement covers the HTTP headers and the contents of payment pages. Headers are half of it, and page content and script integrity are the other half.
See it on your own payment pages.
Install the tag, mark your payment pages, and watch the inventory fill in. Free forever on 1,000 page views a month, no credit card.
Free forever plan. No credit card.