WHEN HACKERS HUNT FOR PAGES YOUR CSP FORGOT
A new Magecart attack shows how dangerous client-side threats become when attackers do not try to break the strongest part of a website, but search for the weakest one. In this case, the attacker looked for pages where Content Security Policy, or CSP, was missing or applied less strictly than on the checkout page. The opening came from a 400 error page. By pulling that unprotected page into a nested iframe chain, the attacker created a trusted-looking browser path for stealing payment data while avoiding controls that were focused on the main checkout experience. To the shopper, the page still looked like a normal payment flow. Behind the scenes, card numbers, expiration dates, CVV values, and other sensitive data could be captured directly from the browser before the transaction ever reached the payment processor.
Attack details
The attack begins by taking over the checkout experience. Instead of simply monitoring the legitimate payment form, the malicious code injects a fake payment interface that includes fields for card number, expiration date, and CVV. The form is built to feel normal to the shopper and includes real-time Luhn validation, which helps the attacker confirm that the card number is properly formatted and likely usable. That validation also reduces the chance that the shopper will notice anything unusual during checkout.
The attacker then begins the more evasive part of the attack. The malicious script is delivered through Google Tag Manager, a trusted tag management service that is commonly allowed by CSP rules, script inventories, and security reviews. That trusted delivery path helps the attacker get code running in the browser without looking like a traditional external skimmer. From there, the script does not simply make an obvious outbound request. It starts building a browser-side tunnel designed to avoid CSP and other monitoring techniques.
The key move is the search for a same-site page without the same CSP protection as the checkout page. The attacker first creates a same-origin iframe pointed at a legitimate local resource, such as a favicon. Because that frame belongs to the same site, the malicious code can use it as a controlled starting point. Inside that frame, the attacker creates another iframe using a path traversal-style request to reach an internal error page. In this case, the attacker found that the 400 page did not carry the stricter CSP applied to the checkout page. That missing coverage allowed the attacker to create a nested iframe environment where the browser treated the activity as part of the trusted site, but the stronger checkout-page policy no longer governed the full execution path.
From that weaker browser context, the final iframe is used to load the exfiltration payload. The attacker also avoids the most obvious network patterns. Instead of relying only on calls such as fetch() or XMLHttpRequest, the code places the outbound destination inside a script src attribute, including through techniques such as setAttribute(‘src’, …). To basic scanners, this can look more like ordinary DOM manipulation than a payment theft attempt. The stolen data is bundled into a Base64-encoded string to reduce the visibility of payment-related keywords, and the script retries the transfer every few seconds to improve the chance of successful exfiltration. Heavy obfuscation further hides suspicious terms, iframe logic, and malicious destinations from simple inspection.
The result is a first-party-appearing attack chain that combines several evasive techniques at once: trusted GTM delivery, fake payment form injection, same-origin iframe control, a 400 page without consistent CSP coverage, attribute-based script loading, encoding, obfuscation, and retry logic. CSP is not defeated by one magic trick. It is avoided through a careful search for uneven policy coverage across the site, then paired with browser behavior that can look normal to tools watching for simpler skimming patterns.
How Source Defense protects you
Source Defense extends visibility to the client side, where this attack takes place: inside the shopper’s browser, before payment data reaches the web server or payment processor. That visibility matters because the most evasive parts of this attack can appear to originate from first-party page contexts, especially after the attacker moves activity into a same-site 400 page without the expected CSP coverage. Source Defense monitors script behavior at the point of input, helping teams identify suspicious access to sensitive fields, risky browser actions, and unexpected data movement even when the attack uses trusted delivery paths and familiar site structures.
Even in this evasive chain, the behaviors that matter remain visible. Payment fields are accessed. Iframes are created to support the tunnel. Risky actions and retry logic help the attack continue. Data transfer activity occurs from the shopper’s browser. Source Defense surfaces those signals so teams can see browser-side abuse that CSP, SRI, WAFs, and server-side logs may miss. Relevant alerts can include:
- Accessing PCI data
- Accessing PII data
- Transferring data
- Executing risky actions, including setTimeout or similar retry logic
- Using browser storage, when applicable
- Using 1st party cookies, when applicable
These alerts appear in the bell notification center and dashboard summaries. Behavioral activity appears in the “Script behaviors” widget when relevant, and alerts can also be sent by email and/or webhook depending on configuration. This browser-level visibility helps teams detect eSkimming activity where it begins and supports PCI DSS 4.0.1 expectations for payment page monitoring and change detection.
Key takeaways
This attack is a reminder that modern eSkimming does not always look like an unfamiliar script making an obvious request to an unknown domain. Attackers can enter through trusted tools, search for forgotten pages, and use normal browser features to make payment theft appear like ordinary site activity. CSP remains valuable, but it must be applied consistently across the full web experience, including error pages and other overlooked responses. SRI, WAFs, and server-side logging also have important roles, but they do not provide complete visibility into what scripts do inside the shopper’s browser. Source Defense helps close that gap by surfacing suspicious access to PCI data, unexpected data movement, and risky client-side behavior, giving teams the visibility they need before browser-side abuse becomes a larger business risk.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.