Notifications
Clear all
Topic starter
18/08/2026 2:17 pm
TL;DR: A KYC provider extended biometric authentication protection from mobile to web to counter crafted video injection, virtual camera bypass, DOM tampering, and reverse engineering, according to Jscrambler. The case shows that passwordless flows still depend on client-side integrity and anti-fraud controls, not just stronger verification logic.
NHIMG editorial — based on content published by Jscrambler: Strengthening Biometric Protection with Jscrambler & Build38
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Harden the web verification runtime Apply client-side integrity controls to the JavaScript and SDK path that performs biometric capture, liveness checks, and submission.
- 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.
- 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.
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
👉 Read Jscrambler's analysis of web biometric protection and client-side fraud controls →
Web biometrics and replay attacks: what identity teams need to watch?
Explore further
18/08/2026 3:10 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Biometric authentication on web raises new client-side fraud controls
