NEW MAGECART ATTACK ABUSES GOOGLE FIRESTORE AND PAYPAL’S BRAINTREE API
A new Magecart campaign shows how dangerous client-side attacks become when they hide inside trusted cloud and payment infrastructure. Instead of sending stolen card data to an obviously suspicious domain, the skimmer used Google Firestore, a Google-hosted database service, to deliver malicious JavaScript and PayPal’s Braintree sandbox API to move stolen data out of the browser. That makes the campaign especially risky for e-commerce teams: traffic to Google and Braintree can look routine, even while card numbers, CVVs, billing details, emails, phone numbers, transaction values, and merchant identifiers are being collected during checkout. The clever twist is not just Magecart, or digital skimming, but Magecart operating through trusted services that may already be allowed by security policies.
Attack details
The attack began with a compromised Google Tag Manager container, making this a first-party-controlled delivery path that triggered third-party activity. The malicious GTM tag fetched JavaScript from a Google Firestore document API under a project name designed to look CAPTCHA-related. Firestore acted like an attacker-controlled content delivery system: the payload could be updated remotely without changing the merchant site.
Once loaded, the JavaScript used several layers of obfuscation, including rotated string arrays, to hide its intent. It targeted common Magento checkout fields for billing address, customer identity, and payment card data, then encoded the harvested information and staged it in localStorage.
A second function retrieved that stored payload, split it across fields, and sent it through a valid-looking Braintree sandbox GraphQL customer creation request. In practice, customer profile fields such as first name, last name, and company were repurposed as containers for stolen payment and identity data.
How Source Defense protects you
Source Defense extends security to the client side, where this attack actually executes, by monitoring script behavior in the browser and controlling what scripts are allowed to do with sensitive data. In this campaign, the critical risk is not simply that a script loaded, but that checkout data was accessed, staged in browser storage, encoded, and transferred through trusted infrastructure. Source Defense helps protect payment pages by detecting and blocking unauthorized script behavior before data exfiltration. This behavior-based approach is especially important when attackers abuse services that may appear legitimate in network logs, CSP policies, or server-side monitoring.
How Source Defense alerts you
Source Defense alerts teams when scripts access sensitive data, use browser storage, transfer data, or execute risky actions in the browser.
Alerts for this campaign would include:
- Accessing PCI data
- Accessing PII data
- Accessing data
- Transferring data
- Using browser storage
- Executing risky actions
These alerts appear in the bell notification center and dashboard summaries. Behavioral findings appear in the “Script behaviors” widget. Depending on configuration, alerts can also be sent by email and/or webhook so teams can act quickly when suspicious checkout behavior appears.
Key takeaways
This campaign shows why client-side security is essential for modern e-commerce protection. CSP, SRI, WAFs, and server-side logs can all play useful roles, but they may miss browser-based threats that operate through approved tags, trusted cloud APIs, and legitimate-looking payment service traffic. The business value of Source Defense is visibility and control at the point of input, before sensitive data leaves the customer’s browser. By focusing on what scripts do, not only where they came from, Source Defense helps merchants reduce Magecart risk, protect payment data, and support PCI DSS 4.0.1 requirements for script control and change detection.
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.