Req 11.6.1: Building a Tamper Detection Mechanism Your QSA Will Accept

There's a requirement in PCI DSS 4.0.1 that sounds deceptively simple: detect when your payment pages change without authorization and alert someone. That's Requirement 11.6.1. It became mandatory on March 31, 2025 — and a year later, it remains one of the most misunderstood and misimplemented controls in the entire standard.

The confusion is understandable. "Tamper detection" sounds like something your server firewall does. In reality, 11.6.1 is specifically about your customers' browsers — and what happens to the scripts and headers on your checkout pages between the moment you deployed them and the moment a customer loads them right now.

What Requirement 11.6.1 Actually Requires

The full requirement states that a mechanism must be in place to alert personnel of unauthorized modifications to the HTTP headers and the contents of payment pages as received by the consumer browser.

Three things buried in that sentence matter enormously:

"As received by the consumer browser" — the requirement is about what the browser actually loads and executes, not what your server sends. A script injected by a compromised CDN, a tag manager container, or a supply chain attack may never touch your server — but it still shows up in the browser. That's what 11.6.1 is watching.

"HTTP headers" — your Content-Security-Policy, HSTS, X-Frame-Options, and other security headers are explicitly in scope. A change to your CSP that opens up a new allowed script source is a tamper event under this requirement.

"Alert personnel" — detection alone isn't enough. Someone has to be notified when a change is detected. A log entry that nobody reads does not satisfy this requirement.

Exactly What Must Be Monitored

Payment page scripts

Every JavaScript file that loads on your payment, checkout, cart, login, and account pages is in scope. This includes inline scripts, external scripts loaded via <script src> tags, and scripts dynamically injected by tag managers. Your tamper detection mechanism must be able to identify when any of these change — a new script appears, an existing script is modified, or a script disappears.

HTTP security headers

The following headers are explicitly relevant to 11.6.1 compliance and must be monitored for unauthorized changes:

• Content-Security-Policy — changes to script-src or connect-src directives are high-risk events
• Strict-Transport-Security — removal or weakening enables downgrade attacks
• X-Frame-Options — change to ALLOW could enable clickjacking on payment pages
• X-Content-Type-Options — removal enables MIME-sniffing attacks
• Referrer-Policy — changes can expose payment flow URLs to third parties
• Permissions-Policy — changes to payment or camera permissions are relevant

What Passes — and What Gets a Finding

This is where merchants get burned. There's a spectrum of approaches to tamper detection, and not all of them satisfy a QSA. Here's how common approaches stack up:

Compliant vs. Non-Compliant: The Real Difference

How to Build a Compliant Mechanism

You have two realistic paths depending on your budget and technical capability:

Path 1 — Purpose-built client-side monitoring tool

This is the clearest path to compliance. Tools like c/side, Feroot, Reflectiz, and Jscrambler are built specifically for PCI DSS 4.0.1 browser-layer monitoring. They inject a small monitoring script into your payment pages, continuously compare loaded scripts and headers against a known-good baseline, and alert your team when anything changes. They produce the audit logs and compliance reports that QSAs expect to see.

Cost ranges from a few hundred to a few thousand dollars per month depending on domain count and feature set. For most e-commerce merchants, this is the most defensible option.

Path 2 — Build it yourself with automation

For technically capable teams, a custom solution is viable — but it must cover all the bases a QSA will check:

1. 1
   Establish your baseline

   Document the current state of every script and HTTP header on each in-scope payment page. This is your known-good reference. Every subsequent scan compares against this baseline. Store it in version control with timestamps.
2. 2
   Automate the scan

   Write a headless browser script (Playwright or Puppeteer work well) that loads each in-scope payment page, captures all script sources, inline script hashes, and HTTP response headers, then compares against the baseline. Schedule it to run at minimum daily — hourly is better. Store results with timestamps.
3. 3
   Build the alert

   Any delta between the current scan and baseline must trigger an immediate alert to a named person or team. Email is acceptable; Slack or PagerDuty is better. The alert must include what changed, on which page, and at what time. "Something changed" with no detail is not actionable.
4. 4
   Document the response procedure

   Write down what happens when an alert fires. Who investigates? What's the escalation path? How is the change classified as authorized or unauthorized? How long before the ticket is closed? This documentation is what a QSA will ask for — and it's what turns a script into a security control.
5. 5
   Maintain audit logs

   Every scan result — including clean results — should be logged with a timestamp. QSAs want to see evidence that the mechanism ran consistently, not just that it exists. Logs should be retained for at least 12 months to cover a full compliance cycle.

Don't Forget the Headers

Script monitoring gets most of the attention, but HTTP header monitoring is equally required under 11.6.1 — and equally neglected. Your tamper detection mechanism must flag when any of the following change on a payment page response:

A Content-Security-Policy that previously blocked unsafe-inline scripts that now permits them is a critical finding. An HSTS header that disappears after a server configuration change leaves your payment pages vulnerable to SSL stripping. These aren't theoretical — they happen every time someone deploys without reviewing security header configuration.

The Most Common Gaps QSAs Flag

No mechanism at all. Still the most common finding a year after the deadline. Merchants assumed their platform handled it, or assumed it was someone else's responsibility. It isn't.

Server-side only. File integrity monitoring on the web server doesn't see what the browser receives. A compromised CDN or tag manager change is invisible to server-side tools.

No alerting. A scan that logs results to a file nobody reads is not a tamper detection mechanism — it's a log file. The alert must reach a human.

No documented owner. If nobody is named as responsible for responding to alerts, the control doesn't exist from a QSA's perspective. Name a person, document the role, test the alert.

Headers excluded. Most DIY implementations focus on scripts and forget headers. The requirement explicitly covers both.

Your Next Step

If you don't currently have an automated, browser-layer tamper detection mechanism covering both scripts and headers on your payment pages — with documented alerting and an audit trail — you have a 11.6.1 finding. The question is whether you find it first or your QSA does.

Start by understanding what's currently on your payment pages. A ClientSideIntel Deep Scan gives you the baseline: every script, every header, mapped against PCI DSS 4.0.1 requirements, delivered as a PDF you can act on and share with your compliance team.