Product deep dive

Client-Side Protection & Compliance

The one place your WAF cannot see: the user's browser. Third-party scripts execute with full access to your DOM, your forms and your customers' keystrokes — and PCI DSS v4.0 now requires you to prove you control them.

The client-side threat

A modern checkout page loads scripts from a dozen origins: analytics, tag managers, chat widgets, A/B testing, personalisation, ad pixels, payment SDKs, session replay. Each executes in the page's origin with the same privileges as your own code. It can read every field of the payment form, modify the DOM, intercept form submissions and send data anywhere.

The attacker therefore does not attack you — they attack the weakest vendor in that chain, or the vendor's vendor. Because the malicious code runs in the browser and exfiltrates directly to an attacker-controlled endpoint, nothing in the request ever reaches your servers, your WAF or your logs. Breaches of this class routinely run for months before detection.

Attack techniques

Technique	Description
Magecart / digital skimming	Malicious JS injected into a checkout page harvests card data as it is typed.
Formjacking	Hooking form submit events or input listeners to copy credentials or PII.
Supply-chain compromise	A legitimate third-party script is modified at its source, or its CDN/hosting is taken over.
Dangling / abandoned domains	A script host domain lapses and is re-registered by an attacker; your page keeps loading it.
Overlay / fake form injection	An additional, attacker-owned payment form is rendered over the legitimate one.
Malicious browser extensions	Client-installed code manipulating the page; visible only from within the browser.
Tag-manager abuse	A compromised marketing account injects a new tag site-wide without any code deployment.

How Client-Side Protection works

The product instruments pages so that script behaviour is observed in the real browsers of real users, then analysed centrally.

Inventory — automatically enumerate every script executing on protected pages, including scripts loaded dynamically by other scripts, with their origin, load path and the pages they appear on. Most organisations discover significantly more scripts than they expected, from vendors nobody can name.
Behaviour monitoring — record what each script actually does: which DOM elements and form fields it reads, which network destinations it contacts, whether it registers input or submit listeners, whether it accesses cookies or storage.
Risk scoring and change detection — compare current behaviour against the established profile. New network destination, new access to a payment field, or a new script appearing on the checkout page are all high-signal events.
Alerting and mitigation — notify with context (which script, which page, which field, which destination) and block the offending behaviour or script.

Behaviour, not signatures. Skimmer code is polymorphic and obfuscated; the constant is what it must do — read a card field and send it somewhere new. Behavioural detection catches novel skimmers on first execution.

PCI DSS v4.0 requirements 6.4.3 and 11.6.1

Two requirements moved client-side script control from best practice to mandatory for payment pages (in force since 31 March 2025).

Requirement 6.4.3 — manage payment page scripts

For every script loaded and executed in the consumer's browser on a payment page you must:

Authorise the script — a documented decision that it may run there;
Assure its integrity — a technical method confirming the script has not been tampered with;
Maintain an inventory of all scripts with written business justification for each.

Requirement 11.6.1 — detect and alert on unauthorised change

Deploy a change- and tamper-detection mechanism that alerts personnel to unauthorised modification of the HTTP headers and the script content of payment pages as received by the consumer browser. It must evaluate at least weekly, or at a frequency justified by a targeted risk analysis.

Mapping controls to requirements

Requirement	What auditors want to see	Control
6.4.3 — inventory	A current, complete list of scripts on payment pages	Automated script inventory, exported per assessment period
6.4.3 — authorisation	Evidence of an approval decision and business justification per script	Approval workflow with recorded justification and owner
6.4.3 — integrity	A method that detects tampering (SRI, hashing, or behavioural assurance)	Subresource Integrity where feasible; continuous behavioural integrity where SRI is impractical
11.6.1 — change detection	Alerting on unauthorised script and HTTP header change, at least weekly	Continuous monitoring with alert history as evidence

Why SRI alone is usually insufficient. Subresource Integrity pins a hash, which works only for scripts whose content is static. Tag managers, analytics and personalisation scripts change constantly and often load further code at runtime, so a pinned hash either breaks the page or is never applied. Behavioural monitoring covers the dynamic majority that SRI cannot.

Complementary hardening

Content-Security-Policy — restrict script-src and, critically, connect-src and form-action, so that even injected code cannot exfiltrate to an arbitrary destination. Deploy with Content-Security-Policy-Report-Only first and collect violation reports; a CSP rolled out blind will break production.
Trusted Types to eliminate DOM XSS sinks in your own code.
Payment iframes / hosted fields — render card inputs inside a PSP-controlled iframe so that page scripts cannot read them. This meaningfully reduces scope but does not remove the requirement to monitor the parent page, which can still be overlaid or redirected.
Vendor governance — contractual security requirements, a named owner per script, and periodic re-justification. Remove scripts nobody can justify; the fastest client-side risk reduction available is deleting unused tags.
Least-privilege tag management — MFA, approval workflow and change alerting on the tag manager, which is otherwise a site-wide code-injection console.

Incident response for a client-side event

Contain fast: block or remove the offending script at the edge — this does not require an application deployment, which is exactly why edge enforcement matters at 2 a.m.
Scope it: which pages, which fields were accessed, over what period, and to which destinations did data go?
Preserve evidence: the script content, behaviour timeline and exfiltration endpoints.
Notify: acquirer/PSP and card brands, regulators under GDPR/CCPA timelines, and affected customers.
Remediate the source: the vendor account, the tag manager, or the compromised upstream CDN — removing the script without fixing the injection path guarantees recurrence.