What is the difference between formjacking and web skimming?

Formjacking is a specific client-side attack in which malicious code is injected into a website’s forms to capture data entered by users. Web skimming is the broader category of attacks that steal payment or personal data from web pages. Formjacking can be one technique used in skimming, but not every skimming attack uses formjacking.

Why the distinction matters for payment-page security

Formjacking and web skimming are often discussed together, but they are not the same thing. The difference matters because teams that treat them as interchangeable can miss where the attacker actually lives: one is a specific injection technique, the other is the broader data-theft outcome across a web page or checkout flow. That distinction changes what needs monitoring, what needs to be hardened, and which controls deserve priority. NIST’s control guidance on software integrity and monitoring helps frame that difference in operational terms. NIST SP 800-53 Rev 5 Security and Privacy Controls

In practice, many security teams discover the problem only after a checkout flow has already been modified and data has already left the page, rather than through intentional review of client-side changes.

How the two attack patterns differ in practice

Formjacking is best understood as a particular method: malicious script is added to a page, usually in or around a form, so that user input can be copied before it reaches the legitimate destination. The attacker is relying on the browser as the place where the theft happens. That means the compromise may be confined to one form, one template, or one site component, even though the impact can be broad if the form collects payment details, account credentials, or identity data.

Web skimming is the wider category. It includes formjacking, but it also covers attacks that harvest data from other parts of the page or checkout experience, such as payment widgets, inline scripts, or manipulated third-party code. In other words, skimming describes the objective and the class of abuse, while formjacking describes one specific injection point and mechanism. A team can have skimming without classic formjacking if the malicious code targets another page element.

That distinction changes the defensive focus. For formjacking, teams need strong attention on script provenance, change control, and unusual DOM or form behaviour. For web skimming more broadly, they also need to consider third-party dependencies, content delivery paths, and the integrity of the full browser execution environment. Client-side controls alone are not enough if untrusted code can still reach the page.

Formjacking is narrower: it targets user forms directly.
Web skimming is broader: it covers multiple ways of stealing data from web pages.
Both depend on the attacker being able to run code in the user’s browser context.
Both can bypass back-end controls if the theft happens before submission.

Where this guidance breaks down is when an organisation has so much client-side variation that it cannot reliably tell which script changed, which flow was affected, or whether the theft came from a form, a tag, or another injected component.

Where the boundary becomes blurry

Tighter client-side monitoring often increases operational overhead, requiring organisations to balance visibility against performance, release speed, and dependency complexity.

In real environments, the line between formjacking and web skimming can blur because modern websites assemble pages from many scripts and services. A malicious change may look like a form issue even when the actual abuse is a broader payment-page skim. Guidance here is consistent: the term should match the mechanism, not the severity. If the attack injects code into a form, formjacking is the more precise label. If the attack steals data from a web page by any client-side means, web skimming is the umbrella term.

There is also a governance edge case. Some teams use “formjacking” as a shorthand for any checkout compromise because it is the better-known term, but that can hide the real control gap. If the issue is a compromised third-party script, the failure is broader than a single form. If the issue is an altered input field or submission handler, the control response may be more targeted. Clear terminology improves incident triage and prevents teams from overfitting the fix to the wrong layer. When the exact injection point cannot be confirmed, teams should avoid overclaiming precision and treat the event as client-side data theft until evidence narrows it further.

Risk and Threat Considerations

The material risk is data theft before the browser ever sends information to the legitimate server. That makes these attacks especially dangerous for checkout pages, account forms, and any workflow that collects payment or identity data. The broader the page assembly chain, the more opportunity exists for malicious client-side code to intercept sensitive fields without breaking the user experience.

Failure mechanism: An attacker gains influence over page-delivered JavaScript, then reads or copies user-entered data from the DOM, form handlers, or injected page elements before submission. The abuse often survives normal server-side logging because the theft occurs in the client runtime, not in the back end.

Impact: Sensitive data can be exfiltrated at scale, customer trust can erode, fraud risk can rise, and incident response may struggle to prove exactly which users were exposed if telemetry on client-side changes is weak.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	16 — Application Software Security	Client-side script integrity is central to form and page skimming.
	8 — Audit Log Management	Detection depends on visibility into page changes and script behaviour.
Recommendation — Harden and review web application code paths that handle user input and embedded scripts. Collect and retain logs that help detect unexpected web asset changes.
NIST CSF 2.0	PR.DS — Data Security	These attacks steal data in the browser before normal submission paths.
Recommendation — Protect data at the point of entry and monitor for client-side data exposure.
MITRE ATT&CK	T1056.007 — Input Capture: Web Portal Capture	Formjacking is a browser-based data capture technique on web pages.
	T1185 — Browser Session Hijacking	Web-page abuse can exploit the browser session and execution context.
Recommendation — Map browser-based capture activity to T1056.007 and hunt for injected page logic. Investigate browser-context abuse when web pages are altered to steal data.

Practitioner Guidance

What to prioritise: Treat terminology as an operational clue. If the issue is isolated to one form, focus on the form path and the code that handles it; if the issue spans a broader page or checkout experience, widen the review to all client-side dependencies and delivery points.

What to verify: Confirm whether the malicious logic sits in the form itself, in a surrounding script, or in a third-party asset. The answer determines whether the event is a narrow form compromise or a broader web-skimming exposure.

Common mistake: Assuming a “payment page” incident always means the same control failure. Teams often miss the distinction between a single injected form handler and a wider script-supply issue, which leads to incomplete remediation.

Practitioner takeaway: Use formjacking when the injection point is the form; use web skimming when the theft description is broader. Precision here improves both triage and containment.