Compliance
Watch every script that can touch your checkout.
Continuous payment-page monitoring: script inventory, change detection, runtime behavior analysis and evidence for the 6.4.3 and 11.6.1 control workflows.
Surfaces this draws on
The problem
The browser is part of the payment attack surface.
A customer reaches checkout. They enter a card number, CVV, billing address and other payment information into the page. The legitimate payment goes through. Everything appears normal.
But JavaScript running on that page may also be able to read the form. If an attacker injects a malicious script, it can silently copy payment information as the customer types and send the data somewhere else.
The merchant sees no failed payment, no outage and no visible warning. This class of client-side payment theft is commonly associated with web skimming and Magecart-style attacks.
Why server-side checks can miss it
The malicious behavior can exist entirely in the shopper's browser.
- The server can remain clean.
- The page loads normally from the merchant's own infrastructure while the malicious behavior comes from a changed or compromised script.
- It may activate only at checkout.
- Testing the homepage or catalog can reveal nothing at all.
- It may wait for real shoppers.
- A skimmer can hold until payment fields are actually populated before acting.
- It can look like analytics.
- Obfuscated JavaScript and unexpected network calls are hard to separate from legitimate marketing, analytics, fraud and checkout tooling.
Third parties widen the trust boundary further. A modern checkout page can load scripts from many external services, so if one trusted supplier is compromised, the merchant inherits the malicious code without changing its own application.
Mapped controls
What PCI DSS 4.0 asks for
Requirement
6.4.3
What it requires
Inventory payment-page scripts, authorize them, and verify their integrity.
What RedMaw contributes
Maintains visibility into the scripts that execute on the checkout page and detects when the observed script set or script content changes, producing an operational record of what was present and what changed.
Requirement
11.6.1
What it requires
Continuously detect and alert on unauthorized change to the payment page.
What RedMaw contributes
Repeatedly loads and evaluates the live page so change is detected closer to the moment it appears. A new script, changed script, altered destination or suspicious behavior becomes an investigable event, preserved as evidence.
Three paths to a skimmer
- 01
Direct compromise
A vulnerable application, plugin, theme or admin account is compromised and used to modify checkout JavaScript.
- 02
Supply chain
The merchant loads JavaScript from a legitimate third party. The third party is compromised. The malicious script reaches every site that trusts that dependency.
- 03
Purely client-side
The behavior occurs in the browser with no obvious server-side payload, which is the difficult case for infrastructure-centric monitoring.
How it works
The Payment-Page Monitor
Script inventory and change monitoring
RedMaw loads the live payment page in a browser context and records which scripts execute and where they load from. Subsequent runs identify new or changed scripts, which is the visibility and change-detection story behind 6.4.3 and 11.6.1.
Behavioral detection
A changed script is not automatically malicious; behavior matters. RedMaw inspects what scripts actually do at runtime. The signal that matters most: a script reading sensitive payment fields, then sending data to a destination that does not fit the established behavior of the checkout page.
CSP and SRI audit
RedMaw evaluates Content Security Policy and Subresource Integrity controls around the payment page. These reduce the freedom an unauthorized script has to load, change or transmit data, so the goal is not only detection but showing where preventative browser controls close the gap.
Exfiltration-domain intelligence
Skimmers need somewhere to send stolen information. RedMaw uses destination context to surface suspicious outbound behavior, including unexpected or look-alike destinations tied to the observed script activity.
Signed evidence and retest
A validated payment-page finding is preserved with technical evidence. After remediation, RedMaw runs the relevant validation again. The security state changes when the exposure changes.
Output
What the evidence package contains
- Payment page tested
- Timestamp and test scope
- Observed script inventory
- Script source and change history
- Detected unauthorized or suspicious change
- Runtime behavior associated with the finding
- Outbound destination context
- Relevant CSP and SRI observations
- Remediation guidance
- Retest result and closure evidence
- Mapping to requirements 6.4.3 and 11.6.1
Why continuous matters here
Payment-page risk appears between scheduled assessments.
A third-party script changes. A plugin update introduces a vulnerability. A compromised dependency begins serving different JavaScript. A new tag is added to checkout.
A point-in-time review does not observe any of those events. RedMaw is built around recurring testing and change-driven validation.
Output
What RedMaw provides for PCI DSS 4.0
All of it produced by the security work itself, not assembled separately at audit time.
- Payment-page script inventory and change history
- Runtime behavioral analysis of script activity
- CSP and SRI audit around the payment page
- Outbound destination context for suspicious behavior
- Signed evidence and retest after remediation
- Control-evidence export for 6.4.3 and 11.6.1
Other frameworks
Same loop, different evidence
Make PCI DSS 4.0 evidence easier to produce.
Continuously validate exposure, preserve the evidence, and re-test remediation.