# PCI DSS 4.0 Client-Side Script Monitoring (Requirements 6.4.3 and 11.6.1)

Source: PageCrawl.io Blog
URL: https://pagecrawl.io/blog/pci-dss-4-client-side-script-monitoring-6-4-3-11-6-1

---

A single line of JavaScript is all it takes. In the Magecart attacks that hit British Airways, Ticketmaster, and Newegg, attackers did not breach a database or crack a password. They injected a few dozen characters of code into a payment page, and that code quietly copied every card number customers typed into the checkout form and shipped it to a server they controlled. The pages looked and worked exactly as before. Nobody on the inside noticed for weeks.

PCI DSS 4.0 was written with this attack class squarely in mind. Two new requirements, 6.4.3 and 11.6.1, became mandatory on March 31, 2025. Together they force merchants to do two things they mostly were not doing before: keep an authorized inventory of every script that runs on a payment page, and detect when the page (or its HTTP headers) is modified without authorization. These are not vague "have a security program" clauses. They are specific, testable controls that a Qualified Security Assessor will ask you to demonstrate.

This guide breaks down what 6.4.3 and 11.6.1 actually require, how the two requirements relate to each other, and how website change detection covers the detection-and-alerting half of the job. If you already track payment-page integrity for PCI, our earlier guide on [PCI DSS 11.6.1 website change detection](/blog/pci-dss-compliance-website-change-detection) is a good companion to this one.

### Two Requirements, One Attack Surface

6.4.3 and 11.6.1 are often discussed together because they defend the same target, the payment page in the consumer's browser, from two different angles.

**Requirement 6.4.3** is about management. You must maintain an inventory of every script loaded and executed on payment pages, confirm that each one is authorized, justify why it needs to be there, and ensure its integrity. This is a governance control: you decide what belongs on the page.

**Requirement 11.6.1** is about detection. You must deploy a change-and-tamper-detection mechanism that alerts personnel when the HTTP headers or the contents of payment pages, as received by the consumer browser, are modified without authorization. The mechanism has to run at least once every seven days, or more often if your targeted risk analysis says so. This is a monitoring control: you catch what slips past 6.4.3.

The key insight is that 6.4.3 defines the baseline ("these scripts are authorized") and 11.6.1 watches for deviation from it ("something on the page changed and nobody approved it"). You cannot do 11.6.1 well without the inventory from 6.4.3, because every alert needs a baseline to compare against.

#### What "payment page" means here

PCI defines a payment page as any web page or form that accepts cardholder data from a consumer's browser. That covers more than the obvious checkout step:

- The checkout page where the card number is entered
- Pages that embed a hosted payment field or iframe (Stripe Elements, Braintree Drop-in, Adyen components)
- Account pages where stored cards can be added or edited
- Subscription and billing-management pages
- Any page that contains, frames, or redirects to the above

If a payment form appears on your domain, even as an iframe you do not control the inside of, the surrounding page and its headers are in scope.

### Requirement 6.4.3 in Detail

The text of 6.4.3 requires that all payment-page scripts loaded and executed in the consumer's browser are managed as follows:

1. **A method is implemented to confirm that each script is authorized.**
2. **A method is implemented to assure the integrity of each script.**
3. **An inventory of all scripts is maintained with written justification as to why each is necessary.**

In plain terms, you need three artifacts you can hand an assessor: an authorization record, an integrity mechanism, and an inventory with justifications.

#### Building the script inventory

Start by enumerating everything that runs on each payment page. This is almost always more than the team expects. A typical checkout page loads:

- Your own payment-handling JavaScript
- The payment processor's client library (Stripe.js, for example)
- Analytics and tag managers (Google Tag Manager, Segment)
- Session replay or heatmap tools
- A/B testing scripts
- Chat widgets and support tooling
- Fraud and device-fingerprinting scripts

Each of these is a potential entry point. If a third party in that list is compromised, their script can be weaponized against your customers without anyone touching your servers. [Magecart groups](/blog/what-is-magecart-client-side-monitoring) have repeatedly used exactly this supply-chain path.

For each script, your inventory needs the source URL or origin, the business reason it is present, who authorized it, and how its integrity is assured. The blunt best practice is also the cheapest control: remove every script from the payment page that does not strictly need to be there. Analytics and chat widgets are convenient, but each one you delete from checkout is one fewer thing to monitor and one fewer supply-chain risk.

#### Assuring integrity

For first-party and pinned third-party scripts, Subresource Integrity (SRI) hashes are the standard integrity mechanism. An SRI hash tells the browser to refuse to execute a script whose content does not match the expected digest, so a silently modified file simply will not run:

```html
<script
  src="https://cdn.example.com/checkout.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>
```

SRI does not work for scripts that legitimately change on every load (some payment-processor libraries are versioned this way), so for those you rely on origin allow-listing through Content-Security-Policy plus active change detection. That is where 11.6.1 comes in.

### Requirement 11.6.1 in Detail

11.6.1 requires a change-and-tamper-detection mechanism deployed to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) of:

- The HTTP headers received by the consumer browser
- The contents of payment pages as received by the consumer browser

The mechanism must evaluate the received header and page, and run at least once every seven days or at a frequency defined by your targeted risk analysis.

The phrase **as received by the consumer browser** is doing a lot of work. It rules out server-side-only checks. A skimmer injected through a compromised CDN, a tag manager, or a man-in-the-middle never touches your origin server's source files, so file-integrity monitoring on the server will not see it. You have to evaluate the page the way a real browser renders it, after all JavaScript has executed and all external resources have loaded.

#### What a browser-perspective check catches

A monitor that renders the payment page in a real browser and compares the result to a baseline detects:

- A new `<script>` tag, especially one pointing at an unfamiliar domain
- A change to an existing script's source URL or its integrity hash
- A hidden form field added to harvest card data
- A modified form `action` that redirects card data to an attacker endpoint
- A new iframe overlaying or replacing the legitimate payment form
- A weakened or removed security header (more on those below)

#### HTTP headers worth tracking

Several response headers are load-bearing for payment-page security, and weakening them is a common precursor to an injection attack. Track these for unauthorized change:

| Header | What it controls | Risk if weakened or removed |
|--------|------------------|-----------------------------|
| Content-Security-Policy | Which scripts, styles, and origins the browser may load | Opens the door to script injection from new domains |
| Strict-Transport-Security | Forces HTTPS for the connection | Enables downgrade and man-in-the-middle attacks |
| X-Frame-Options | Whether the page can be framed | Enables clickjacking of the payment form |
| X-Content-Type-Options | MIME-type sniffing protection | Lets disguised content execute as script |
| Referrer-Policy | Referrer data sent on requests | Leaks sensitive URL parameters |

A change to Content-Security-Policy is the one to watch most closely. CSP is your primary structural defense against script injection, so an attacker who can quietly relax it has cleared the path for everything else.

### How Website Change Detection Covers 11.6.1

A website change-monitoring tool handles the detection-and-alert half of these requirements directly. It loads each payment page in a real browser on a schedule, captures the fully rendered content and the response headers, compares them to the last known-good state, and notifies your team when something differs.

#### Mapping the requirement to monitoring features

| 11.6.1 / 6.4.3 need | What the monitoring tool does |
|---------------------|-------------------------------|
| Evaluate page as received by browser | Renders the page with JavaScript executed, not raw server HTML |
| Detect content changes | Diffs current rendered content against the baseline |
| Detect header changes | Captures and diffs HTTP response headers each check |
| Alert personnel | Sends email, Slack, Teams, or webhook on any change |
| Run at least every 7 days | Schedules checks from weekly down to every few minutes |
| Support the script inventory (6.4.3) | Surfaces new or changed scripts as content diffs to review |
| Provide assessor evidence | Retains timestamped screenshots and a full change history |

It is worth being honest about the boundary. A change-detection tool tells you that the page or its headers changed and shows you exactly what changed. It does not, on its own, decide whether a change was authorized. That judgment, comparing the diff against your deployment records and your 6.4.3 inventory, stays with your team. The tool removes the impossible part (noticing the change at all) and leaves you the tractable part (confirming it was expected).

### Setting Up Payment-Page Monitoring with PageCrawl

Here is a practical setup that satisfies the detection side of 6.4.3 and 11.6.1.

**Step 1: Inventory and add every payment page.** From your 6.4.3 work you already have the list. Add each checkout page, hosted-form container, account billing page, and subscription page as a monitor. PageCrawl ships with screenshots enabled by default, which is exactly what you want here: every check stores a timestamped image of the rendered payment page as the customer would see it.

**Step 2: Capture the full rendered page, not raw HTML.** Use full-page content monitoring so the page is rendered in a real browser with JavaScript executed. This is what makes the check "as received by the consumer browser" rather than a server-side source diff that misses dynamically injected skimmers.

**Step 3: Track the HTTP headers.** Monitor the response headers alongside the content so a weakened Content-Security-Policy or a removed Strict-Transport-Security header triggers an alert. If you want to watch one specific header value rather than the whole page, a targeted [CSS selector or element-level approach](/blog/css-selector-guide-target-elements-monitoring) keeps the diff focused on what matters.

**Step 4: Set a risk-based frequency.** Weekly is the floor, not the goal. PageCrawl's free tier checks every 60 minutes, and paid tiers go down to every 2 minutes. Match frequency to transaction volume:

- High-volume checkout (1000+ transactions/day): every few minutes to hourly
- Medium volume (100 to 1000/day): a few times per hour to a few times per day
- Low volume (under 100/day): daily
- Bare minimum compliance: weekly (document the risk analysis that justifies it)

**Step 5: Route alerts to the people who can act.** Configure multiple notification channels so a change reaches your security and incident-response teams immediately. Email for routine changes, [Slack or Teams alerts](/blog/website-change-alerts-slack) for fast team visibility, and a [webhook into your SIEM or incident platform](/blog/webhook-automation-website-changes) for automated triage. A webhook payload lets you open a ticket and page on-call the moment an unexpected script appears.

**Step 6: Keep the evidence.** PageCrawl retains the full change history with timestamped screenshots, which is the artifact a QSA wants to see: proof the monitoring ran, what it caught, and when. For long-term retention, pair it with a [website archiving workflow](/blog/website-archiving) so you hold the 12 months of records PCI expects.

### Handling Legitimate Changes Without Alert Fatigue

The hard operational problem is not catching changes, it is separating your own deployments from attacks. Every release that touches a payment page will fire an alert, and a team that learns to ignore alerts is worse off than one with no monitoring at all.

A workable process looks like this:

1. **Notify before you deploy.** When the team ships changes to a payment page, post a heads-up to the same channel that receives monitoring alerts so the next alert is expected.
2. **Verify against the diff.** When the alert fires, compare what PageCrawl shows changed against what the deployment actually changed and your 6.4.3 inventory. Matches get documented and the baseline is updated.
3. **Exclude noisy dynamic content.** Session tokens, cart timestamps, and rotating nonces change on every load and are not security-relevant. Scope monitoring to the structural parts of the page (scripts, forms, headers) so these do not generate constant false positives.
4. **Escalate the unexpected.** Any change that does not map to a known deployment is a potential incident. That is the path to investigation, and the whole point of the control.

This baseline-and-verify loop is what turns a stream of diffs into a clean signal. It also produces the investigation records assessors ask for.

### What Assessors Want to See

When a QSA evaluates your 6.4.3 and 11.6.1 controls, they typically ask for:

- **The script inventory** with authorization and written justification for each entry (6.4.3)
- **Integrity evidence**, such as SRI hashes or CSP allow-lists, for payment-page scripts (6.4.3)
- **Tool configuration** showing payment pages are monitored at the documented frequency (11.6.1)
- **Alert and change history** proving the mechanism is active and alerts are reviewed (11.6.1)
- **Investigation records** showing how detected changes were triaged and resolved
- **A targeted risk analysis** justifying your check frequency if it is less often than weekly

A monitoring tool with retained, timestamped history covers the last four directly. The first two come from your 6.4.3 governance work, which the monitoring then watches over.

### Beyond the Minimum

Meeting 6.4.3 and 11.6.1 is the floor. A few measures meaningfully raise the ceiling:

#### Strict Content-Security-Policy

A tight CSP that allow-lists only the exact script origins your payment page needs can block most injection attacks outright, even when an attacker manages to alter the page. Treat CSP as a structural control and monitor the header itself for any loosening.

#### Subresource Integrity everywhere it fits

Apply SRI to every script and stylesheet on the payment page that does not legitimately change per load. A modified file then simply fails to execute in the browser, converting a stealthy compromise into a visible breakage you will notice fast.

#### Monitor the script files, not just the page

A skimmer can be introduced by changing the contents of an already-allowed JavaScript file without altering a single line of the payment-page HTML. Monitoring the individual bundle URLs and their hashes catches this class of change that page-level monitoring alone can miss.

Many of these controls overlap with broader programs. If your organization tracks obligations across multiple frameworks, our overview of [regulatory compliance monitoring](/blog/regulatory-compliance-monitoring) and the deeper [compliance monitoring software](/blog/compliance-monitoring-software) guide cover the workflow at scale.

### Choosing your PageCrawl plan

PageCrawl's **Free plan** lets you monitor **6 pages** with **220 checks per month**, which is enough to validate the approach on your most critical pages. Most teams graduate to a paid plan once they see the value.

| Plan | Price | Pages | Checks / month | Frequency |
|------|-------|-------|----------------|-----------|
| Free | $0 | 6 | 220 | every 60 min |
| Standard | $8/mo or $80/yr | 100 | 15,000 | every 15 min |
| Enterprise | $30/mo or $300/yr | 500 | 100,000 | every 5 min |
| Ultimate | $99/mo or $999/yr | 1,000 | 100,000 | every 2 min |

Annual billing saves two months across every paid tier. Enterprise and Ultimate scale up to 100x if you need thousands of pages or multi-team access.

Compliance monitoring is the cheapest insurance you can buy. A single missed regulatory change can trigger fines in the tens or hundreds of thousands, not to mention the audit overhead of proving you did not see it coming. Enterprise at $300/year covers 500 regulatory pages with unlimited history and timestamped screenshots, which is usually exactly what an assessor wants to see. All plans include the **PageCrawl MCP Server**, so your compliance team can ask Claude to summarize every change to a specific regulation over the last quarter and pull the exact diff, turning your monitoring history into a queryable audit trail. AI assistants can create monitors through conversation on every plan, including Free, and paid plans add on-demand checks and monitor management. Standard at $80/year is enough to cover 100 pages across your primary regulatory bodies if your program is smaller.

### Getting Started

Start with the pages that matter most. Take your three or four highest-traffic checkout and payment pages and set up full-page browser-based monitoring on each, with HTTP-header tracking turned on and screenshots enabled. Run it daily at minimum, and route alerts to the channel your security team already watches.

Run it for two weeks and pay attention to the alert volume. You will quickly learn which page elements change for legitimate reasons (and should be scoped out) and which changes deserve investigation. Use that period to build the verify-against-deployment habit, so a real injection would stand out immediately against the noise you have already tuned away.

Once the loop is working, expand to your full inventory of payment pages and pair it with your 6.4.3 script list so every alert has a baseline to check against. The free tier covers 6 pages and includes the screenshots and change history that double as assessor evidence, which is enough to prove the approach before you scale it across the rest of your checkout flow.

---

Need more? The complete PageCrawl.io help center, with every article, is available as a single document at https://pagecrawl.io/llms-full.txt. Read it for context on anything this page does not cover.