Payment-page security guide
Client-Side Script and Magecart Protection: PCI DSS Guide
Every script able to read a checkout page, every tag-manager change, and every security-impacting response header belongs in the payment-page attack surface.
On this page
E-skimming can enter through a compromised platform, administration account, third-party JavaScript, supply-chain dependency, or XSS. Treat browser-received scripts and headers as a controlled production surface, not as an untracked outcome of marketing or deployment tooling.
Overview
Outcome
Establish a payment-page programme that authorises scripts, verifies integrity, detects browser-observed tampering, preserves safe evidence, and supports a narrow incident response.
Understand the PCI DSS 4.0.1 outcomes
Requirements 6.4.3 and 11.6.1 have been effective since 31 March 2025. For payment-page scripts loaded and executed in a consumer browser, the organisation must confirm authorisation, assure integrity, and maintain an inventory with business or technical justification. It must also detect and alert on unauthorised changes to security-impacting HTTP headers and payment-page script content as received by the browser. PCI DSS defines outcomes, not a mandatory CSP, SRI, edge, or monitoring product.
- Approved baseline
Each script, origin, purpose, owner, and review date is recorded.
- Controlled delivery
Build, tag-manager, header, and edge changes follow change control.
- Browser observation
Headers, scripts, redirects, and hashes are compared with approved state.
- Alert and response
Unauthorised differences are contained with evidence preserved.
A reliable inventory follows the browser-delivered page through approval, integrity verification, tamper detection, and response.
Build a script inventory the browser can prove
Inventory first- and third-party scripts, dynamic loads, tag-manager rules, iframes, final URLs after redirects, owner, purpose, approval, hash or version where usable, page scope, data-access rationale, and rollback path. A build dependency list alone is insufficient because a tag-manager or vendor can change browser-delivered code outside the application repository.
| Control | What it does | What it does not prove |
|---|---|---|
| CSP | Limits permitted script, connection, form, frame, and object sources | That every allowed script is authorised or unchanged |
| SRI | Pins a stable external resource to an expected digest | A mutable vendor URL or tag-manager programme is safe |
| Browser tamper detection | Compares delivered headers and content with approved baseline | Root cause or data-exposure scope by itself |
| Edge header delivery | Makes policy consistent and observable | Full payment-page compliance alone |
page=/checkout
script=https://static.example.com/checkout.8f3a.js
owner=payments-platform purpose=payment-form release=2026.07.15
integrity=approved-hash change_ticket=SEC-184
browser_check=pass csp_origin=allowlisted review_due=2026-10-15Use CSP and SRI as defence in depth
Use a checkout-specific, HTTP-delivered CSP with deliberate script-src, connect-src, form-action, frame-src, frame-ancestors, base-uri, and object-src policies. Start in report-only mode, remove legitimate violations, then enforce. Apply SRI to stable external scripts where an expected hash and CORS behaviour are controllable. Do not blindly add nonces or integrity attributes at the edge: automatic nonce insertion can authorise attacker-injected scripts.
Detect tampering and respond narrowly
Compare the page a browser receives with an approved baseline: HTML, script URLs and hashes, redirects, tag-manager content, and security-impacting headers. Alert on additions, deletion, unexpected origins, altered SRI, or changed checkout connection destinations. Preserve headers, page snapshot, hashes, timestamp, release identifier, and alert decision, but never PAN, CVV, form values, tokens, or sensitive query strings.
Troubleshooting
Payment-page security anti-patterns
- Treating a CSP or SRI deployment as proof of PCI DSS compliance.
- Keeping analytics, experimentation, chat, or marketing code on checkout without checkout-specific justification.
- Detecting only build-time dependencies instead of the delivered browser page.
- Logging form bodies or payment data while investigating a script alert.
Related guides
Authoritative references
- PCI SSC Document Library
- PCI SSC: Payment Page Security and Preventing E-Skimming
- OWASP Third-Party JavaScript Management Cheat Sheet
- W3C Content Security Policy Level 3
- W3C Subresource Integrity
Make payment-page changes evidence-ready
Optimi can help align edge policy, browser-observed checks, and incident evidence around the scripts and headers serving checkout.
Review payment-page security