PCI Payment Page Script Audit: requirement 6.4.3 and 11.6.1 on your checkout markup

Twenty findings sit in an ordinary checkout page, and the e-commerce developers who own that template in the US and the EU are the ones who have to clear them. The page renders correctly. Payments go through. Nothing in it looks wrong, because none of these are bugs - they are a requirement that has been mandatory since 2025-03-31 and that nobody put on the sprint board.

PCI DSS 4.0.1 requirement 6.4.3 says that every script loaded and executed in the customer's browser on a payment page needs three things: a method that confirms the script is authorized, a method that assures its integrity, and an inventory entry with a written business or technical justification for why it is there. Requirement 11.6.1 adds that you have to be alerted when the scripts or the security headers of that page change.

Here is the head of a checkout page that passes every other check you run.

<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline' https:">
<script src="https://www.googletagmanager.com/gtag/js?id=G-8QK2M1RS"></script>
<script src="https://cdn.jsdelivr.net/npm/jquery@latest/dist/jquery.min.js"></script>
<script src="https://static.hotjar.com/c/hotjar-2914455.js?sv=6"></script>
<script src="https://js.stripe.com/v3/"></script>

Five lines, and four separate failures:

• The policy is in a <meta> tag. A meta policy cannot carry report-uri or report-to - the browser ignores both there. So it can block, but it can never tell you it blocked, and 11.6.1 asks for exactly that alert.
• script-src allows 'unsafe-inline' and bare https:. Every host on the internet is an authorized script source, which is the opposite of an authorization method.
• The tag manager can add a script tomorrow that no inventory records. That is not a hypothetical; it is the normal way a marketing tag reaches a checkout page.
• jquery@latest is a moving version. Whatever hash you wrote down at assessment time describes bytes that may no longer be served.

And one line that is fine and gets flagged by naive tooling: js.stripe.com is supposed to load without a Subresource Integrity hash, because Stripe rotates that file. Demanding a hash there is wrong. It still needs an inventory row, with "renders the hosted card fields" as its justification.

The thing that changed this year

Merchants with a fully outsourced checkout used to have a way out. If the payment page was entirely delivered by the processor, a QSA could agree that 6.4.3 and 11.6.1 were not applicable, and that agreement was enough to write it into the report.

On 2026-08-04 the PCI Security Standards Council published a revised FAQ 1331. QSA agreement alone is no longer sufficient: merchants must consult their Compliance Accepting Entity - the acquirer or the payment brand - to confirm what applies. The requirements did not change. The escape route narrowed, and it narrowed inside an assessment cycle that many teams are already in.

Why the tools you already have do not cover this

A CSP evaluator grades the policy string. It never opens your page, so it cannot see the script the page injects at runtime with document.createElement('script'). ESLint reads JavaScript; it does not read the attributes of a <script> tag, so integrity= with no crossorigin= - which browsers ignore, leaving you unprotected while the markup claims otherwise - goes straight past it. And an assistant that was trained before this year will confidently tell you Subresource Integrity is sufficient for 6.4.3, which is the single most common wrong answer in this area: SRI does not inventory anything, does not apply to dynamically injected scripts, and does not notice when an authorized script starts behaving differently.

What the audit does

It reads the page as markup, line by line, against 26 rules written for payment pages specifically. Each finding names the line, the requirement it fails and the replacement. Session recorders on a page with a card field. Marketing pixels that ship without a justification. <base href>, which quietly rewrites every relative script URL on the page. eval() and new Function(), which force 'unsafe-eval' into the policy and remove the CSP as an authorization method for everything else. Inline handlers, which force 'unsafe-inline' and do the same.

The free version audits the page you have open, completely: all 26 rules, no key, no watermark, no locked results. It runs in the editor and it runs as a single web page you can paste a template into.

What a licence adds is not more rules - it is the artifact. An assessor does not accept a findings panel; they accept a dated inventory. The full version exports that inventory as CSV, JSON or HTML across every payment page in the repository, and emits CI output that fails a build when an unauthorized script appears, so the next tag someone pastes in does not reach production between assessments.

A PCI consultant bills about $76 an hour in the US in 2026, and a QSA-assisted self-assessment runs $5,000 to $20,000. Building this inventory by hand is billed inside that, and it has to be rebuilt every time marketing adds a tag.