Preventing Deepfakes and Injection Attacks in Face Verification

The Attack Surface of a Selfie

Face verification has become the front door of digital identity — which makes it the front door fraudsters attack. Understanding the attack taxonomy is the first step to defending your KYC flow or face login, because different attacks require different defenses.

There are two fundamentally different places to attack a face verification system:

In front of the camera — presentation attacks (spoofs shown to a real camera)

Behind the camera — injection attacks (fake video fed into the system, bypassing the camera entirely)

Presentation Attacks: Photos, Screens, and Masks

Presentation attacks show the camera something that isn't a live face:

• Print attacks — a printed photo of the victim, sometimes with eye holes cut out

• Replay attacks — the victim's photo or video displayed on a phone/tablet screen

• Mask attacks — from paper cutouts to silicone masks

These are cheap, require no technical skill, and defeat naive face matching completely — a photo of you is your face, as far as an embedding model is concerned. Matching accuracy and similarity thresholds are irrelevant here; you need presentation attack detection (PAD), better known as liveness detection.

• Passive liveness analyzes a single frame for spoof artifacts: screen moiré patterns, print texture, unnatural color and depth cues. Zero user friction.

• Active liveness issues a challenge — turn your head left, look up — and verifies the response in video. Much harder to satisfy with a static artifact.

Our active vs. passive comparison covers when each fits. For most flows, passive liveness on every capture plus active liveness on high-risk events (onboarding, payment limits changes, account recovery) is the right layering.

Deepfakes: The Replay Attack, Upgraded

Generative models changed the economics of face fraud. Off-the-shelf tools now produce:

• Face swaps — the victim's face composited onto an attacker's live video in real time

• Reenactment — a single photo of the victim animated to smile, blink, and turn on command

• Fully synthetic identities — faces of people who don't exist, used to pass "is this a real person" checks in synthetic identity fraud

A real-time face swap can defeat naive active liveness: the attacker performs the head movements, and the deepfake renders the victim's face performing them. Defending requires looking for generation artifacts — temporal flicker, boundary blending, physically inconsistent lighting, missing micro-texture — signals modern liveness models are specifically trained on.

The industry response is measurable: financial-sector fraud reports across Southeast Asia show deepfake-enabled fraud attempts growing multiples year over year, which is why regulators in the region increasingly expect liveness detection in KYC.

Injection Attacks: Bypassing the Camera Entirely

The most technically sophisticated attacks never show anything to a camera:

• Virtual camera software presents a video file or deepfake stream as a webcam device

• Instrumented mobile apps (rooted/jailbroken devices, hooking frameworks) replace the camera feed inside the app

• API replay — captured or synthetic images submitted directly to verification endpoints, skipping the client app

Defenses live at a different layer than PAD:

Server-side liveness — never trust a client-side "liveness passed" flag; the server must analyze the actual media. A liveness verdict computed on the device that captured (or faked) the video is worthless against an instrumented client.

Challenge unpredictability — active liveness instructions generated server-side per session (as ARSA's active liveness request endpoint does) mean a pre-recorded deepfake can't know the challenge sequence in advance.

Client attestation — mobile platform integrity APIs (Play Integrity, App Attest) raise the bar for instrumented devices.

Rate limiting and anomaly detection — injection at scale looks like abnormal API traffic; per-key rate limits and request logging surface it.

API key hygiene — replayed requests need credentials; scope and protect them per our API key security guide.

Defense in Depth: The Reference Stack

No single control stops all three attack classes. A production-grade verification flow layers:

Capture guidance — good framing and lighting improves both matching and liveness signal quality

Passive liveness on every submission — catches prints, screens, and most replays with no friction

Active liveness on high-risk events — server-generated challenges defeat pre-rendered media

Face matching with a calibrated threshold — after liveness, verify identity via 1:1 validation or 1:N search

Server-side enforcement — all verdicts computed server-side, all attempts logged and rate-limited

Risk-based step-up — velocity checks and device signals decide when to escalate from passive to active

How ARSA Implements This

The ARSA Face Recognition API ships the biometric layers of this stack: passive liveness detection on single images, active liveness with server-generated head-pose challenges and video verification, and a combined submit-and-recognize endpoint that runs the liveness check and identity match in one call. All processing happens server-side; per-key rate limits and full request logging are built in — see our security overview.

Fraud techniques will keep improving. The teams that stay ahead treat face verification not as a feature checkbox but as an adversarial system needing layered, updatable defenses. Test the liveness endpoints free against your own spoof attempts — a photo of your own screen is a surprisingly effective first red-team exercise.