Biometric authentication on web raises new client-side fraud controls

At a glance

What this is: This is an analysis of how a biometric identity verification provider extended protection from mobile to web and found that client-side manipulation remained a core fraud risk.

Why it matters: It matters because identity teams need to secure the channel where verification happens, since replay, injection, and tampering can undermine even privacy-preserving biometric authentication flows.

👉 Read Jscrambler's analysis of web biometric protection and client-side fraud controls

Context

Biometric authentication reduces password reliance, but it does not remove the need to defend the browser or mobile runtime where verification is executed. In practice, fraud teams and IAM owners still have to assume that replayed media, synthetic inputs, and script tampering can target the client-side path before the identity decision is made.

For identity verification programmes, this creates a boundary problem between fraud prevention and access control. The provider in this case avoided storing biometric data, which helps privacy, but the security model still depends on liveness checks, SDK integrity, and resistance to runtime manipulation. That is a typical pattern for modern digital identity systems, not an edge case.

Key questions

Q: What breaks when biometric verification is only protected on mobile but not on web?

A: Attackers move to the weaker channel and target replay, injection, or DOM tampering there. If the web SDK is less protected, the same identity assurance can collapse even when the mobile flow is hardened. Teams should assess assurance parity across channels, not just the strongest implementation, because attackers only need one weak verification path.

Q: Why do biometric login flows still need runtime integrity controls?

A: Because biometric decisions depend on the code that captures, processes, and submits the signal. If attackers can modify JavaScript, patch functions, or tamper with the DOM, they can alter the verification path without defeating the biometric method itself. Runtime integrity protects the trust boundary around the decision, which is where abuse often occurs.

Q: How can identity teams tell whether liveness checks are actually working?

A: Look for adversarial cases that still pass when motion is synthetic, partial, or replayed from a static image. Effective programmes test whether liveness outcomes remain stable when the same applicant reappears with different devices, names, or document data. If the control only succeeds in clean test conditions, it is not robust against fraud reuse.

Q: Should organisations treat privacy-preserving biometrics as enough for secure authentication?

A: No. Avoiding biometric storage reduces privacy exposure, but it does not stop client-side abuse or account takeover. Security teams should pair privacy design with fraud resistance, code integrity, and channel-specific assurance reporting so the authentication model remains trustworthy under active attack.

Technical breakdown

How web biometric verification is attacked at the client side

Web biometric verification is exposed to the same hostile conditions as any browser-delivered security control. Attackers can inject crafted video, replay a captured stream, or bypass a camera feed by presenting a virtual device to the web SDK. They can also tamper with the DOM, patch JavaScript functions at runtime, or interfere with objects the application depends on for liveness and challenge-response logic. These attacks do not need to break the biometric model itself. They only need to corrupt the client-side signals before the verification decision is made.

Practical implication: protect the verification runtime, not only the biometric workflow.

Why code integrity matters for biometric and KYC flows

Code integrity tools are designed to detect or prevent runtime manipulation of application logic in the browser. In this context, they help preserve the trustworthiness of the JavaScript that drives biometric capture, liveness testing, and submission of verification data. Anti-DOM tampering and anti-monkey patching controls make it harder for attackers to alter the page state or replace native functions that security logic depends on. That matters because client-side authentication controls are only as reliable as the code path that implements them.

Practical implication: pair verification logic with runtime integrity controls for the web channel.

Cross-platform protection and the risk of inconsistent control coverage

When mobile and web channels use different protection layers, attackers look for the weaker path. A mobile SDK may be hardened against injection and reverse engineering while the web experience remains exposed to browser-specific manipulation. Cross-platform defence reduces that asymmetry by aligning the trust model across devices and channels. For identity programmes, that alignment is important because users increasingly move between mobile onboarding, desktop verification, and browser-based step-up authentication within the same journey.

Practical implication: review identity control consistency across mobile, web, and step-up journeys.

Threat narrative

Attacker objective: The attacker wants to bypass liveness checks and gain unauthorized access without needing the victim's credentials.

1. Entry begins with the attacker feeding a crafted video stream or virtual camera input into the web verification flow.
2. Escalation occurs when runtime manipulation targets the SDK, DOM, or JavaScript functions that validate liveness and session trust.
3. Impact follows when the manipulated client-side path allows unauthorized account access through a compromised biometric verification process.

NHI Mgmt Group analysis

Client-side biometric integrity is now an identity control, not just an application control. If the browser or SDK can be manipulated, the biometric decision inherits that corruption regardless of how strong the underlying identity proofing logic appears. That is why identity verification teams have to treat runtime integrity as part of the authentication architecture, not a separate engineering concern. Practitioners should align fraud, IAM, and application security ownership around the client-side trust boundary.

Privacy-preserving biometrics still need anti-abuse controls. Not storing biometric data reduces some privacy risk, but it does not prevent replay, injection, or virtual camera attacks. The governance lesson is that privacy design and abuse resistance solve different problems, and both must be present for digital identity assurance to hold. Teams should evaluate where biometric claims end and where fraud controls begin.

Cross-platform identity consistency is a named governance gap: verification parity drift. When mobile protection is mature but web controls lag, attackers simply shift channels. This creates uneven assurance across the same user journey and undermines programme confidence in passwordless adoption. Practitioners should map assurance levels per channel and close gaps before expanding biometric verification to more interfaces.

Web SDK tamper resistance belongs in the same control conversation as liveness assurance. Liveness checks answer whether a live person is present, but they do not guarantee the code evaluating that signal has not been altered. That distinction matters for regulated KYC providers and any identity platform that must prove the integrity of its verification path. Practitioners should combine signal integrity and code integrity in the same assurance model.

What this signals

Client-side identity controls are becoming part of the trust fabric for digital identity programmes, especially where biometric verification meets browser-based delivery. The practical signal is that identity teams should measure assurance by channel, not by product category, because the same user journey can have different attack surfaces in mobile and web.

Verification parity drift: when one channel is protected more deeply than another, the weaker path becomes the attacker’s preferred route. That means IAM, fraud, and application teams need shared evidence for liveness, runtime integrity, and anti-tamper coverage across the entire authentication journey.

For identity programmes that already rely on passwordless authentication, the next step is not adding another factor by default. It is proving that the client-side code path cannot be altered in ways that invalidate the biometric claim, and that evidence should be reviewed alongside broader access governance.

For practitioners

• Harden the web verification runtime Apply client-side integrity controls to the JavaScript and SDK path that performs biometric capture, liveness checks, and submission. Focus on DOM tampering, function patching, and injected scripts because those are the points where browser-side verification is most often subverted.
• Test replay and virtual camera abuse cases Build red-team scenarios for crafted video injection, replayed streams, and virtual camera bypass against the web channel. Use the results to verify whether your liveness controls fail closed when inputs are synthetic or instrumented.
• Define channel-by-channel assurance levels Document whether mobile, web, and step-up authentication journeys provide equivalent protection or whether one channel is materially weaker. Where coverage differs, treat that as a governance issue rather than an implementation detail.
• Separate privacy claims from anti-fraud claims If no biometric data is stored, record that as a privacy control, but do not confuse it with resistance to replay or tampering. Use different control owners and evidence for privacy posture and for client-side attack resistance.

Key takeaways

• Biometric verification is only as trustworthy as the client-side code that implements it.
• Web replay, virtual camera bypass, and DOM tampering remain practical threats to passwordless identity flows.
• Identity teams should govern assurance parity, runtime integrity, and fraud resistance as one control set.

Key terms

• Client-Side Integrity: Client-side integrity is the assurance that browser or app code has not been altered in ways that change security behaviour. In identity verification, it protects the trustworthiness of the capture, validation, and submission path before the server makes an authentication decision.
• Liveness Detection: Liveness detection is the mechanism that checks whether a biometric sample comes from a real, present person rather than a spoof such as a photo, screen, or mask. In identity programmes, it is a core defence against presentation attacks and should be tested under realistic operating conditions.
• Verification Parity Drift: Verification parity drift is the gap that appears when one authentication channel has materially stronger controls than another. In digital identity programmes, it creates inconsistent assurance across mobile, web, and step-up flows, which attackers can exploit by shifting to the weakest route.
• Runtime Manipulation: Runtime manipulation is the alteration of application behaviour while code is executing, often through script injection, function patching, or DOM tampering. For biometric systems, it can corrupt the signal path without defeating the biometric method itself.

What's in the full article

Jscrambler's full article covers the implementation detail this post intentionally leaves for the source:

• The PoC findings from simulated DOM tampering, anti-monkey patching, and runtime manipulation tests on the web SDK
• The performance considerations that determined whether the protection could run without degrading the user experience
• The mobile-to-web protection transition details, including how the team extended safeguards across both channels
• The operational guidance the development lead received while fine-tuning the code protection setup

👉 The full Jscrambler article covers the PoC, runtime protection details, and the web SDK hardening approach.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and identity lifecycle fundamentals. It is designed for practitioners who need to connect identity assurance to broader access and security governance.