A Holistic Look at eSkimming: From Formjacking to Full Funnel Manipulation

How modern website attacks evolve inside the browser, and what to do about it

It starts like a lot of incident reviews do. Fraud and chargebacks spike. Support tickets roll in. Someone swears they saw a weird payment prompt. The security team pulls logs, checks the WAF, hunts for obvious indicators server-side and finds nothing. Checkout still works. The payment processor looks normal. No suspicious API calls, no obvious backend compromise. Then someone finally looks where the attacker actually operated: inside the user’s browser.

That is the reality behind modern eSkimming. It was never just protect the “card theft on the payment page.” Attackers work the entire funnel, gaining the ability to observe, manipulate, and exfiltrate data at the point of input, often through the same third-party scripts your site depends on to function and grow. Here we’ll take a look at the lifecycle of these attacks and a realistic plan to reduce risk.

Why “payment page only” thinking breaks down

PCI forced the industry to pay attention to scripts on payment pages, and that helped. But attackers were never just focused there. They stage earlier, learn what they need, then trigger theft or manipulation at the moment it matters. A big reason is that the modern website is effectively a JavaScript supply chain. Analytics, personalization, A/B testing, chat, tags, and “just one more snippet” all introduce code that executes in every session, often owned outside engineering. 

Meanwhile, the browser became the attack surface. If an attacker can run JavaScript in the user’s session, they can read inputs, change the DOM, and send data out without touching your servers. The opinionated takeaway: if you model checkout as a single page, you’ll keep defending a spot attackers are happy to bypass.

What “full funnel” looks like in one incident

Here’s the pattern security teams keep running into: An attacker gains execution through a compromised third-party script or a tag manager publish path. They do not immediately steal card data. Instead, they watch the funnel. They hook into fields upstream (email, phone, login, shipping), learn what payment options exist, and only then inject a believable overlay at checkout. 

The overlay collects card data and may even pass the user through to the real flow so the purchase still completes, reducing suspicion. That is why teams can spend days staring at server logs and find nothing. The theft happened before the request existed.

Common attacker behaviors you’ll actually see

Rather than splitting this into “manipulation techniques” and “exfil patterns,” it’s more useful to think in terms of what their code does during runtime. Keep in mind that a lot of this activity can occur while everything still looks “authorized” on paper.

• Hooks into sensitive fields (credentials, address, payment inputs)
• Creates overlays or swaps form elements to redirect user input
• Injects new fields or “verification” prompts that feel plausible
• Stages data in browser storage and sends later to avoid obvious spikes
• Uses reputable infrastructure or rotating endpoints to blend in
• Triggers only under certain conditions (cart value, geo, device, user action)
• Reinserts itself through the same delivery path after cleanup

Here’s the compact model you can use to align security, web engineering, and whoever owns your tags and scripts. This reduces the conversation from “we need more tools” to “we need control at the execution layer.”

Why traditional controls often miss this

Most security stacks are strongest where telemetry is centralized: servers, APIs, identity, and network. But these attacks happen in the browser at runtime. A WAF can’t see DOM manipulation. Backend monitoring won’t catch keystrokes captured before submission. And allowlists or point-in-time integrity checks struggle in dynamic environments where scripts legitimately change frequently and trusted delivery paths can be abused. The takeaway is that you cannot govern your way out of runtime behavior. Governance reduces exposure, but you still need visibility into what scripts are doing while they execute.

A plan you can run with

30-day plan

• Establish a script baseline across key funnel pages, not just checkout
• Lock down high-risk publishing paths (especially tag managers)
• Alert on meaningful deltas: new scripts, new destinations, suspicious DOM changes on login and checkout

Quarterly plan

• Add runtime visibility into script behavior and block unauthorized access patterns
• Build an incident playbook for browser-side compromise (delivery path, rollback, validation)
• Formalize vendor and script governance: ownership tags, approvals, periodic review

If your 30-day plan does not include “who can publish tags and scripts” you are fixing symptoms, not the infection.

Three practical takeaways

If you take nothing else from this, remember this: your website is not just a UI layer sitting politely on top of your backend. It’s an execution environment where third-party and first-party code runs inside every customer session, and that is exactly where these attacks live.

That’s why eSkimming isn’t a checkout-only issue. Attackers stage upstream, learn the flow, and manipulate or steal at the moment it matters. If you only defend the payment page, you’re defending a single room in a house with the windows open.

The practical path forward is twofold: tighten governance so you know what code is running and who can change it, and pair that with runtime visibility so you can see what scripts actually do in the browser and stop the ones that cross the line.

Request a Demo

If you want to see what runtime visibility and control looks like in practice, request a demo of Source Defense. In 30 minutes, we’ll show how teams:

• Discover and inventory scripts across funnel pages
• Detect and block malicious behavior at the point of input
• Reduce exposure from third-party code without slowing the business
• Support PCI DSS 4.0 requirements 6.4.3 and 11.6.1

See how Source Defense helps security teams reduce eSkimming risk across the full funnel.