---
title: "Client-Side Script and Magecart Protection: PCI DSS Guide"
description: "Protect payment pages from Magecart and e-skimming with script inventory, authorisation, integrity controls, CSP, SRI, tamper detection, and PCI DSS 4.0.1 guidance."
canonical_url: https://optimi.com/en/guides/client-side-script-magecart-protection
md_url: https://optimi.com/en/guides/client-side-script-magecart-protection.md
last_updated: 2026-07-15
---

# 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.

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.

## 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.

**Payment-page control loop**

1. Approved baseline — Each script, origin, purpose, owner, and review date is recorded.
2. Controlled delivery — Build, tag-manager, header, and edge changes follow change control.
3. Browser observation — Headers, scripts, redirects, and hashes are compared with approved state.
4. 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.*

**Browser-observed payment-page changes close the control loop**

![Flowchart from an approved script and header inventory through controlled delivery to a browser-delivered payment page. A comparison either records a verified baseline or alerts on a mismatch, contains the change, restores approved state, and returns to the inventory.](/diagrams/client-side-script-magecart-protection/browser-tamper-loop.svg)

*The browser-received page is the control point: an approved build alone cannot prove that scripts, redirects, and headers remained unchanged in delivery.*

## 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 |

**Representative script inventory record**

```
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-15
```

## Use 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.

## 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

- [E-commerce Edge Architecture](/en/guides/ecommerce-edge-architecture)
- [Website Security Incident Response Plan](/en/guides/website-security-incident-response)
- [Security Headers](/en/guides/security-headers)

## Authoritative references

- [PCI SSC Document Library](https://www.pcisecuritystandards.org/document_library/)
- [PCI SSC: Payment Page Security and Preventing E-Skimming](https://blog.pcisecuritystandards.org/new-information-supplement-payment-page-security-and-preventing-e-skimming)
- [OWASP Third-Party JavaScript Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html)
- [W3C Content Security Policy Level 3](https://www.w3.org/TR/CSP3/)
- [W3C Subresource Integrity](https://www.w3.org/TR/SRI/)

[Review payment-page security](/en/contact): 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.