PCI DSS 6.4.3

PCI DSS 6.4.3: controlling client-side scripts on payment pages

Requirement 6.4.3 turns payment page scripts into a managed asset. Teams need to know what executes, who approved it, why it is needed, and how integrity is controlled.

9 min

June 1, 2025

3 official sources

In this article

A static spreadsheet quickly becomes outdated; the inventory should reflect the real page.

Every payment page script needs an owner, status, and business justification.

CSP, SRI, and monitoring work best as layers in a managed process.

Contents

Next practical step

If you want to move from theory to a pilot, start with one payment flow, its baseline, and the change scenarios around it.

Discuss a pilot

Key points

A static spreadsheet quickly becomes outdated; the inventory should reflect the real page.

Every payment page script needs an owner, status, and business justification.

CSP, SRI, and monitoring work best as layers in a managed process.

What 6.4.3 expects

The requirement is not only about listing script URLs. It is about making browser-side code on payment pages governable and reviewable.

A strong implementation combines live discovery, authorization workflow, integrity checks, and evidence retention.

Three layers of control

A practical model separates script inventory, script authorization, and integrity assurance. Missing one layer makes the control harder to defend during audit.

  • Inventory: first-party, third-party, and dynamically loaded scripts.
  • Authorization: owner, purpose, approval, review date, and status.
  • Integrity: SRI, CSP, signatures, monitoring, or other change-control mechanisms.

Why a manual spreadsheet is not enough

Manual inventories drift quickly. Marketing tags change, payment SDKs update, CDNs serve new versions, and tag managers can load scripts dynamically.

The inventory should be based on the real page and the browser activity around it, not only on what the team planned to deploy.

How to connect 6.4.3 with delivery

New scripts should pass through an owner, a business reason, an authorization decision, and a technical check before they reach the production payment page.

Useful controls include CI quality gates, CSP in report-only before enforcement, hash or signature validation where appropriate, and a documented exception process.

Practical steps

1

Build a live inventory of payment page scripts.

2

Assign an owner and business justification to every script.

3

Add integrity or authenticity controls to the change process.

4

Review the approved state regularly and retain evidence for audit.

Questions on this topic

Is CSP enough for PCI DSS 6.4.3?

No. CSP is useful, but it does not replace the need for an inventory, authorization status, business justification, and evidence.

Can the script inventory be maintained manually?

A manual inventory can be a starting point, but production checkout pages change too often for a static list to remain reliable. The stronger approach is to compare the real page against the approved state.


Need a fast payment page security pilot?

Cartelta helps capture the baseline, detect payment page changes, and prepare evidence for internal teams and QSA review.

Related articles

PCI DSS 4.0.1

PCI DSS 4.0.1: what changed for online businesses

A practical overview of PCI DSS 4.0.1 for e-commerce teams, payment pages, client-side script controls, and audit evidence.

Read article

PCI DSS 11.6.1

PCI DSS 11.6.1: payment page change detection

How PCI DSS 11.6.1 applies to payment page change detection, critical headers, DOM monitoring, and incident response evidence.

Read article

Cartelta JSIR

How Cartelta JSIR supports PCI DSS 6.4.3 and 11.6.1

A practical scenario for using Cartelta JSIR to inventory scripts, detect changes, and prepare evidence for payment page security controls.

Read article

© 2026 Cartelta. All rights reserved.

Send request