Injection attack
Feeding the verification system a video that never passed through the camera. What it is, how it differs from a presentation attack, and why it is the vector biometric certifications do not evaluate.
In short
An injection attack, in identity verification, is the substitution of the video stream before it reaches the application that will evaluate it. The attacker shows nothing to the camera: they use a virtual camera, an emulator, or manipulation of the device itself to hand the system an image of their choosing.
The physical camera is never involved. Everything the system receives looks like a normal capture, and that is the whole point of the attack.
In application security the same name designates a different family of attacks, code or command injection against a database or an interpreter. These are different concepts that share a word: what is injected here is a video stream, not an instruction.
Presentation happens in front of the camera. Injection avoids it
The two vectors can carry the same deepfake, and they are stopped with different controls.
- Presentation attack — the attacker shows something to the device's real camera: a printout, a screen, a mask. The camera works and captures whatever is in front of it.
- Injection attack — the attacker replaces what the camera should be delivering. The image never passed through a lens.
The question that separates the two is short. Presentation is a problem of what is in front of the camera. Injection is a problem of whether there is a camera at all.
The vector that biometric certification does not cover
It is worth stating this precisely, because it is where the market gets confused the most and where a comparison between providers gets decided badly.
The ISO/IEC 30107-3 standard defines the method and metrics for evaluating presentation attack detection in biometric systems: an accredited lab builds attack instruments, presents them to the system under controlled conditions, and measures how many are accepted. Its scope ends at the capture device.
The Levels 1 and 2 often cited alongside the standard do not belong to the standard. They are grades in iBeta's testing program, which applies that methodology, and differ by the cost and sophistication of the attack instruments. VU is certified by iBeta at Level 2 of that program.
The vector this page describes falls outside what that methodology measures. No certification obtained under that standard says anything about it, VU's included. It is a separate control, bought or built separately, and it pays to ask any provider for its own evidence on it.
Where it shows up in an identity journey
- Account signup with biometric capture — the most exposed moment, because the organization does not yet have any prior reference for that person.
- Access recovery with a face — where a flow is resolved by comparing against the capture from signup.
- Authorizing operations by biometrics — the confirmation a system asks for before a high-value action.
- High-volume remote channels — those running in the browser or in applications that do not control device integrity.
The controls that respond to this vector are not biometric: they are about integrity. Detecting virtual cameras and emulators, verifying the origin of the image, and checking the execution environment. Several depend on what the operating system and the device manufacturer expose, so no identity provider solves them alone.
The full sequence of the attack is on the fraud-type page: video injection attack.
Frequently asked questions
It is the substitution of the video stream before it reaches the application that evaluates it, using a virtual camera, an emulator, or manipulation of the device. The system receives an image chosen by the attacker and treats it as if it came from the camera. Not to be confused with the code injection used against databases, which shares the name and has no relation to it.
In a presentation attack, content is shown to the device's physical camera, which normally captures whatever is in front of it. In an injection attack the camera is not involved at all: the stream gets replaced beforehand. Liveness detection answers the first vector; the second is covered with device-integrity and image-origin controls.
No. Its scope is presentation attacks, the ones that happen in front of the capture device, and it defines the evaluation method and metrics for those. Levels 1 and 2 belong to iBeta's testing program, which applies that methodology, not to the standard. When comparing providers it pays to be clear on exactly what each result measures and to ask for separate evidence for the other vector.
