AN HONEST MISTAKE, A COSTLY LEAK: CREDIT CARD ESKIMMING BY ACCIDENT
What looked like a textbook eSkimming incident on a WooCommerce checkout turned out to be something even more unsettling. A trusted analytics script loaded from the domain api.config-security[.]com, which appears to be related to a third-party integration, potentially involving Triplewhale and was first highlighted by @PPJSteyn in a post on X, was unintentionally collecting and sending credit card data off-site. While that post framed the behavior as a Shopify issue, the underlying risk comes from how this third-party script handled data in the browser.
No attacker compromised the site, no malicious domain was involved, and no policy was technically “broken” – yet payment data still left the browser, creating real PCI exposure.
This is the modern client-side problem in a nutshell: sometimes the riskiest incidents aren’t exploits, they’re small implementation mistakes that trusted scripts faithfully – and dangerously – act on.
Incident details
During checkout testing, credit card entry triggered browser-side requests that resembled classic Magecart behavior: compressed, encoded payloads leaving the page immediately after payment data was typed.
The destination wasn’t attacker infrastructure – it belonged to a legitimate telemetry provider, perhaps Triplewhale, which meant the “skimmer” was actually normal tracking logic doing what it was configured to do.
The root cause was a subtle front-end mislabeling: the credit card field was marked as a telephone-style input to improve mobile UX, so the telemetry script classified it as a non-sensitive phone field and eligible for collection.
As a result, the card number was captured as interaction telemetry, packaged up, and transmitted to a third party that is not a payment processor, producing the same practical impact as an eSkimming attack, without any malware.
How Source Defense protects you
Source Defense focuses on what scripts do in the browser – not just whether they’re “trusted” – so it can catch scenarios where allowlisted services behave unsafely.
In this case, Source Defense would identify that a third-party script is interacting with payment inputs and that the browser session is transmitting data to an external domain (including which domain), and enforce runtime controls that prevent such unauthorized scripts from accessing PCI-relevant fields in the first place.
By blocking access at the point of collection, Source Defense helps eliminate the downstream risk of sensitive data being packaged and sent externally – even when the script and destination are legitimate.
How Source Defense alerts you
Regardless of whether you’re running active protection or detect-only monitoring, Source Defense will generate alerts when scripts exhibit risky runtime behavior – even if the script and destination domain are legitimate.
In detect-only mode, those alerts give you immediate visibility so your team can investigate and respond; in protect mode, the same behaviors can be proactively blocked in real time before sensitive data leaves the browser.
In this scenario, customers would see alerts such as:
- Accessing PCI data – a third-party script interacting with payment fields in a way that indicates exposure risk
- Transferring data – the browser session sending data externally, including visibility into the destination domain
These alerts surface in the notification center and dashboard summaries, giving security teams a clear signal that “allowed” client-side behavior is creating real payment-data risk.
Key takeaways
Client-side security failures aren’t always “attacks”- they can be trusted scripts behaving as designed in the wrong context.
In this case, controls like CSP allowlists and vendor trust didn’t help, because they govern what’s permitted to load and where browser traffic is allowed to go; not whether sensitive user input is being picked up during runtime.
The practical lesson is: “trusted script + allowed destination” isn’t enough. You also need visibility into what scripts are doing in the browser, so you can catch sensitive-input collection and unexpected outbound telemetry even when everything looks legitimate.
Because with client-side code, an honest mistake can still become accidental eSkimming — and the damage doesn’t care about intent.
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.