Nobody Knows What Scripts Are On Your Checkout Page, And In 2026 That Is An Audit Finding

There is a specific kind of compliance failure that does not announce itself until an assessor is already in the room, and PCI DSS requirements 6.4.3 and 11.6.1 are shaping up to be the 2026 version of it. Both requirements became mandatory on 31 March 2025, at the end of the long future-dated grace period that shipped with PCI DSS v4.0 and carried through into v4.0.1. That means 2026 is the first assessment cycle in which essentially every merchant and service provider being tested has had no remaining excuse for treating them as best practice. The requirements are about scripts running in the browser on payment pages, which is territory most engineering teams have never had to formally control, and the timing could not be more awkward, because the browser layer is exactly where AI-generated code has been quietly accumulating.

The two requirements are short and their intent is plain. Requirement 6.4.3 says that for every script loaded and executed in the browser on a payment page, you maintain an inventory, you authorise each script, you have a written business justification for why it is there, and you have a method to assure the integrity of each one. Requirement 11.6.1 says you deploy a change detection or tamper detection mechanism that alerts on unauthorised modification to the HTTP headers and the content of the payment page as received by the browser, and that the mechanism runs at least weekly or at a frequency your targeted risk analysis defends. Read together they are an inventory obligation and a monitoring obligation over a surface that most teams have historically treated as somebody else problem.

These requirements exist because of e-skimming, and the threat model is worth stating precisely, because it explains why server-side hardening does not help. In a Magecart-style attack the server is never breached. The attacker compromises a third party that your page already trusts, an analytics vendor, a tag manager container, a chat widget, a font or a CDN, and modifies the script that browsers fetch. The modified script reads the card fields as the customer types and posts them to an attacker endpoint. Your logs look clean, your WAF sees nothing unusual, your infrastructure is untouched, and cardholder data leaves the browser before it ever reaches you. The only place the attack is visible is in the browser, which is why the standard now demands controls that live there.

Now put that next to how checkout pages get built in 2026. A founder spins up a storefront in Bolt, v0 or Lovable, or lets Cursor and GitHub Copilot scaffold a payment flow, and what arrives is a page that works beautifully and imports a small crowd of third parties by default: an analytics snippet, a session replay tool, a support widget, a fonts host, a consent banner, a marketing pixel, sometimes a tag manager that can inject arbitrary further scripts at runtime. None of that is a defect in the tools, it is the convention of modern frontend code and the models learned it faithfully. The problem is that AI generation removes the friction that used to create a paper trail. When a human developer added a third-party script there was at least a pull request and a reviewer who asked why. When a model adds six of them in one generation, the justification step never happens, and requirement 6.4.3 is precisely a demand for that missing justification.

The gap shows up as a very specific conversation with a QSA. The assessor asks for the inventory of scripts on the payment page, and the team produces a source file rather than an inventory, which is not the same artefact. The assessor asks who authorised the session replay tool to run on a page containing card fields, and there is no answer because nobody made a decision, a model did. The assessor asks how integrity is assured, expecting subresource integrity hashes, a content security policy that actually restricts sources, or a client-side monitoring product, and finds a page that loads scripts from wildcards. The assessor asks for evidence that tamper detection ran weekly for the whole period under review, and there is no such mechanism at all. Four questions, four findings, and none of them are hard to fix in advance, which is what makes it a painful way to fail.

Fixing it is mechanical work that a small team can do in a week. Start by generating the inventory from reality rather than from the repository: load the payment page in a browser, capture every script actually requested including the ones injected at runtime by a tag manager, and write each one into a table with its source, its owner and one sentence saying why it is allowed near a card field. That exercise alone usually deletes two or three scripts, because the honest answer for some of them is that nobody remembers adding them. Then reduce what remains: the cleanest architecture is to keep card fields inside a payment provider iframe so your own page never touches the data, which changes which self-assessment questionnaire applies to you and shrinks the whole problem. For what is left, add subresource integrity hashes where the resource is versioned, tighten the content security policy to named hosts rather than wildcards, and stand up a monitoring mechanism that compares the delivered page and headers against a known good baseline and alerts a human when they drift.

It is worth being clear about where your existing compliance tooling helps and where it does not, because this is a common and expensive misunderstanding. Vanta, Drata, Secureframe and Sprinto are genuinely good at policy management, control mapping and continuous evidence collection across ISO 27001, SOC 2 and increasingly ISO 42001, and if you already run one of them the change management and secure development controls you evidence there carry real weight in a PCI assessment. What none of them do is watch the browser. Client-side script integrity needs a mechanism that observes what a real browser actually loads on a real payment page, and that is a different category of product. The efficient posture is to let the GRC platform hold the inventory, the justifications and the review cadence as controls, and let a client-side monitoring tool feed it the evidence. Do not assume a green dashboard in a compliance platform means requirement 11.6.1 is covered, because by default it is not.

The wider lesson generalises past payments, and it is the same one running through everything we cover on AI governance. AI tools have made it trivial to add dependencies and near impossible to remember that you did. The control that matters in that world is not a smarter code review, it is an inventory you regenerate from what is actually running, plus monitoring that tells you when the running thing changes. PCI DSS happens to have written that principle into a standard first because card data made the consequence immediate, but ISO 27001 asks the same question about your software inventory in A.8 and ISO 42001 asks it about your AI systems. If you take one action after reading this, open your checkout page in a browser, look at the network tab, and count the third-party scripts. If the number surprises you, you have just found your 2026 audit finding several months before your assessor does, which is the only good time to find it.