← All posts

PCI DSS 11.6.1: detecting payment page changes

CentralCSP Team

CentralCSP ·

Requirement 6.4.3 makes you approve every script on your payment page. Requirement 11.6.1 assumes that approval will not hold forever. A vendor's CDN gets compromised, a tag manager account is phished, someone edits the checkout template, and the page your customers receive is no longer the page you approved. 11.6.1 asks you to notice, and to be alerted, when that happens.

Like 6.4.3, it has been mandatory since 31 March 2025 and is unchanged in PCI DSS v4.0.1. This guide covers what the requirement says, which changes count, how often the check must run, how CSP reporting and script monitoring map to it, and what an assessor accepts as evidence.

The requirement text

PCI DSS v4.0.1 states:

A change- and tamper-detection mechanism is deployed as follows:

  • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the security-impacting HTTP headers and the script contents of payment pages as received by the consumer browser.
  • The mechanism is configured to evaluate the received HTTP headers and payment pages.
  • The mechanism functions are performed at least weekly, OR periodically (at a frequency defined in the entity's targeted risk analysis, according to all elements specified in Requirement 12.3.1).

Four ideas are packed in there: detect a modification, alert a person, cover both headers and scripts, and do it as received by the consumer browser.

The PCI SSC information supplement of March 2025 adds a useful framing: 11.6.1 "recognizes that unauthorized changes might occur". It does not require you to prevent every change. It requires that a change is recognized and generates an alert "so corrective actions can be taken promptly". An unauthorized change then usually triggers a fresh 6.4.3 review of the script concerned.

What counts as an unauthorized modification

The supplement lists three cases for both headers and scripts:

  • Newly appears: a new header or script, "for example, a second CSP directive or a new JavaScript (.js) file".
  • Is changed: an existing header or script is altered, or "changes behavior from the previously authorized state".
  • Is deleted: "a header like a CSP directive or a defensive script is removed".

The third case matters more than it looks. An attacker who wants to run a skimmer on a page with a strict Content Security Policy (CSP) does not need to bypass the policy if they can remove it. A detection mechanism that only watches for new scripts misses that.

Which HTTP headers are "security-impacting"

The supplement gives examples and says the right set depends on your architecture: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, X-XSS-Protection, X-Content-Type-Options, Set-Cookie, Access-Control-Allow-Origin, Referrer-Policy, Permissions-Policy, and the Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy and Cross-Origin-Resource-Policy trio.

In practice, for a checkout, the headers that most change your exposure are the CSP (it decides which scripts may run and where data may go), HSTS, the framing controls, and the cookie attributes. Start there and document why the list is what it is.

Why "as received by the consumer browser" matters

A scan of your repository, a file-integrity check on your web server, or a review of your deployment pipeline all look at the page before it reaches the shopper. 11.6.1 names the other end. The page a browser assembles includes scripts fetched directly from vendors and CDNs, scripts injected at runtime by a tag manager, and headers that a CDN or edge layer may add or strip. None of that is visible from your origin.

The mechanism therefore has to look at the page from the outside, the way a browser does: from real sessions, from a synthetic browser that loads the page, or from a proxy in front of it.

How often it must run

At least weekly, or at a frequency you set in a targeted risk analysis (TRA) under requirement 12.3.1. The supplement adds a caution worth repeating: "malicious modifications could persist without detection between those times, so frequent or even real-time monitoring is recommended where feasible."

Weekly is a floor, not a target. A skimmer that runs for six days before a weekly crawl catches it has had six days of card numbers. If you choose a longer interval than weekly, the TRA is part of the evidence and the assessor will read it.

The mechanisms that can meet it

The supplement accepts a single mechanism or several that "collectively meet the requirement". It gives examples: "automated or manual transaction simulations, real-time monitoring platforms, and third-party script services". In tool terms:

  • Agent-based monitoring: a script on the payment page watches the DOM, network requests and script behavior in real sessions. Drawback named by the supplement: it must be integrated into each page and can affect performance.
  • Agentless monitoring: a headless browser walks the checkout on a schedule. It sees headers and scripts, but "may struggle with CAPTCHAs, logins, or state-based flows" and only sees what its own sessions load.
  • Proxy-based: a reverse proxy or CDN inspects HTML and scripts on the way out. It can see headers and enforce policies, with configuration and latency trade-offs.
  • CSP with reporting: the browser itself reports blocked or executed scripts from real sessions. The supplement credits CSP with "partial detection of unauthorized additions or modifications" and is clear about its limits (below).

How CSP, reporting and script monitoring map to 11.6.1

The supplement's Table 4 lists CSP as a control for alerting, for script content changes, for script indicators of compromise and for frequency, but not for security-impacting headers. That is accurate, and it shapes a realistic design:

11.6.1 elementWhat covers it with browser reportsWhat it does not cover
A script from a new origin appearsCSP violation report from any current browser, in a real sessionScripts from an origin your policy already allows
A new script file appears, even from an allowed origincsp-hash report with 'report-sha256': every executed script, by URLFirefox does not send hash reports yet
An approved script's content changesA different SHA-256 for the same URL in csp-hash reportsCross-origin scripts served without CORS carry no usable hash
A script is removedIts reports stop arrivingAbsence is a weak signal; review the inventory for scripts no longer seen
A security header changes or disappearsNot covered by CSP reportsNeeds a header check: synthetic, proxy, or scheduled request
AlertingA collector that compares reports with your approved baseline and notifies a personCSP itself sends reports, not alerts

In short: browser reports are a strong fit for the script half of 11.6.1, from real sessions and continuously. The header half needs a mechanism that reads the response headers.

A minimal header check can be as simple as a scheduled job that fetches the payment page and compares the headers you care about with a stored baseline:

curl -sI https://shop.example.com/checkout \
  | grep -iE '^(content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy):' \
  | tr -d '\r' | sort > headers-today.txt
diff headers-baseline.txt headers-today.txt || notify-security-team

Run it at least weekly (daily costs nothing), alert on any difference, and keep the output. Cookie attributes need a separate comparison because Set-Cookie values change on every request. A nonce-based CSP also changes on every response, so strip the nonce value before comparing. The free security headers scanner shows what a page sends today when you build the baseline.

Alerting and response

11.6.1 says "alert personnel". An entry in a dashboard nobody opens is not an alert. The supplement's examples of alerting methods include email, SMS, SYSLOG events, Windows security log events and vendor logs. Chat channels and webhooks into your ticketing or on-call system are the modern equivalents.

The alert also has to lead somewhere. Requirement 12.10.5 requires your incident response plan to include "monitoring and responding to alerts" from the payment page change- and tamper-detection mechanism. The assessor may ask to observe the process, or a table-top exercise if there has been no real incident.

Decide in advance what happens when an alert fires: who looks at it within what time, how they tell an expected vendor release from a compromise, and who can pull a script from the checkout.

What counts as evidence

The supplement's Table 9 lists what an assessor expects for 11.6.1:

  • System settings of the change- and tamper-detection mechanism.
  • The list of monitored payment pages.
  • Results from monitoring: "logs, reports, or other results".
  • Configuration showing the mechanism detects and alerts on unauthorized changes to headers and script contents, and evaluates the received headers and pages.
  • The documented TRA, if you run less often than weekly.
  • Configuration and interviews confirming the frequency.

Add the roles and responsibilities for 11.6.1 (requirement 11.1.2) and the incident response plan entry (12.10.5). The supplement also notes you can use your 6.4.3 script inventory to configure the mechanism, which is how most teams tie the two requirements together: the inventory is the baseline, and 11.6.1 alerts on departures from it.

Practical tip: keep a few real alerts and the record of how each was handled. An alert history with outcomes is stronger evidence than a configuration screenshot.

Where CentralCSP fits

CentralCSP covers the script side of 11.6.1 from real browser traffic, with nothing added to the checkout. It collects CSP violation and hash reports for your payment pages and compares them with the approved inventory you built for 6.4.3. Alert rules then notify Slack, Microsoft Teams, Google Chat, Telegram, email or a webhook when:

  • a script appears on a payment page and nobody has justified it (New unjustified script),
  • a script on a payment page serves content nobody has justified, including one approved at its previous hash (Unjustified script change), with the reviewed and current hashes in the notification,
  • a script origin is seen for the first time (New script origin).

Every detection, hash change and decision lands in an append-only ledger, and the evidence export hands the assessor a PDF report plus complete CSVs of the inventory and the change ledger. Data is hosted in France, on OVH.

Two limits. Hash reports come from Chromium browsers and Safari only, not Firefox, so the script inventory reflects that traffic, while violation reports come from every current browser. And CentralCSP's PCI alerts do not compare HTTP response headers, so pair it with a header check like the one above. CentralCSP helps you meet 11.6.1; your QSA decides whether the evidence is sufficient. See the PCI DSS page and the alert rules documentation.

Frequently asked questions

Is a weekly crawl enough for 11.6.1?

It meets the minimum frequency, but a skimmer can run for days between two crawls, and a crawler only sees what its own sessions load. The PCI SSC recommends frequent or real-time monitoring where feasible.

Does a CSP satisfy 11.6.1 on its own?

No. CSP reports help detect unauthorized scripts and script changes, but a CSP does not alert anyone by itself, keeps no baseline, and cannot detect that a security header was changed or removed. You need a collector that turns reports into alerts, plus a header check.

Does 11.6.1 apply to SAQ A merchants?

SAQ A no longer lists it since January 2025. If your page embeds a provider's payment form, the SAQ A eligibility criterion asks you to confirm the site is not susceptible to script attacks, which PCI SSC FAQ 1588 says you can do by applying techniques such as 6.4.3 and 11.6.1, or with written confirmation from your provider. See the 6.4.3 guide.

Does 11.6.1 apply to the page that embeds a payment iframe?

Yes. The PCI SSC supplement places the parent page that embeds a payment iframe in scope for both 6.4.3 and 11.6.1. Pages that only redirect to a provider's hosted page are not.

Sources