General Security Recommendations
This article covers common cyberattacks and the steps you can take to stay safe.
Cyberattack Types
The most common cyberattacks can be divided to three groups: injection, integration, and presentation attacks. Below, you’ll find some examples for mobile and web SDKs.
Injection Attacks
An injection attack on a liveness detection system is an attempt to bypass liveness verification mechanisms by injecting falsified data or modifying the execution logic of the frontend SDK. This type of attack is typically carried out by code injection, tampering with the runtime environment, or replacing camera input components (e.g., intercepting and substituting the video stream in real time, using virtual cameras, or manipulating JavaScript logic in the Web SDK). The goal of such attacks is to trick the liveness system into accepting fake or pre-recorded content as a genuine live interaction with the user.
Examples for mobile SDKs:
Virtual cameras.
File system integrity compromise.
Function hooking & application modification.
Emulators and cloud devices.
For web:
Virtual cameras.
Code injection attacks.
Presentation Attacks
A presentation attack is an attempt to deceive the system by presenting pre-recorded or artificial content that mimics a real user. The goal of such attacks is to pass the liveness check without involving a real, live person. These attacks do not target the SDK directly but rather the biometric models on the backend. They may include:
Photos,
Videos,
3D masks,
Screens of other devices, or
Other media used to create the illusion of live presence.
Other (System Manipulation) Attacks
These attacks include cyber fraudsters manipulating how the liveness detection module is integrated into the application or backend, bypassing or faking the check. Typically, these attacks involve patching the app, injecting hooks, or exploiting weak verification of liveness results. For instance, Man-in-the-Middle (MitM) / SSL Interception attack that is based on substitution or manipulation of captured data during network transmission, typically involving SSL/TLS violations or certificate pinning bypass.
Oz Software Built-In Security Measures
With cyberattacks on the rise, cybersecurity has become crucial and is now our highest priority. We provide protection even from multi-vector complex attacks, ensuring your data is safe at all stages of processing, including media capture, data transmission, and analysis. This protection involves many mechanisms on multiple layers that work together, supporting and reinforcing each other. To name a few:
We do not accept virtual cameras and emulators.
In native SDKs, you can configure SSL pinning and add protection for media files using request payload.
For Web SDK, you can move the decision logic to backend to avoid manipulating data within the browser context.
As our software aims to be embedded, it includes mechanisms to verify its runtime integrity, but it does not validate the integrity of the host application itself. Ensuring protection of the host application through anti-tampering techniques, code obfuscation, and runtime integrity verification is the responsibility of the host application owner. Without such safeguards, even a secure SDK may become susceptible to manipulation at the application or platform level.
Recommendations for Host Application Protection
Here are some measures we recommend to protect your application.
Consider revising your policies. This might involve:
Creating and using corporate SSL certificates,
Limiting access to unverified sources,
Using SSL proxy,
Controlling connections via SNI / TLS Handshake,
Creating a security policy and adhere to it,
etc.
For mobile applications, use Play Integrity (Android) and App Attest (iOS).
As for our SDKs, we recommend:
Ensuring you always have the latest version of Oz software installed, as almost each of our releases includes security enhancements.
Setting up SSL pinning for Native SDKs.
For Web SDK, retrieving and processing the analyses' results on your backend to avoid possible manipulations within the browser context, and using the Safe mode when setting up responses.
For more detailed recommendations, please contact us. For us, clients' safety comes first, and we’ll be happy to help.
Last updated
Was this helpful?
