If you run trust and safety or security at a social platform, dating app, or adult site, your age check has a target on it. The moment a face estimate or a document scan decides who gets in, someone will try to fake the face, bypass the camera, or reuse a pass that was never theirs. Knowing how those attacks work is the first step to shutting them down.

In a Nutshell

• An age estimator only judges how old a face looks. It cannot tell you whether that face is live, real, or the user's own, so a correct estimate can still be the wrong decision.
• Fraudsters beat age checks four ways: a photo or screen held to the camera, fake video injected past the camera, a replayed result, and a borrowed or shared account.
• Presentation attack detection, injection detection, session binding, and holder binding each stop a different attack. None of them alone stops all four.
• Deepfakes are not a single attack. They show up across every layer, so you defend against them at each one, not with a single score.
• Match the strength of your controls to the risk of the feature, not to every user.

A passing age check is not a secure one

An age model answers one question. How old does this face look? That is an analysis job, and modern models are good at it. Security is a different job. It has to establish that the face is live, that it reached your app through the real camera, and, where it matters, that it belongs to the person in front of you. When a system treats "the model returned 30" as proof of a safe user, it skips every one of those steps.

How can a correct age estimate be the wrong decision?

Picture a 15-year-old holding up a sharp photo of a 30-year-old. The estimator returns 30. The model is right about the face it sees, and the access decision is wrong, because the face on screen is not the person seeking access. Every attack below exploits that same gap between reading a face and trusting where it came from. So the useful question is not "is the model accurate?" It is "can I trust this input?"

How do fraudsters spoof the camera?

The simplest attack puts a fake in front of the lens. This is a presentation attack, and the artifact can be a printed photo, a face on another screen, a video replay, a mask, or manipulated media. The control that catches it is presentation attack detection, or PAD, which reads the visual and timing cues that separate a live person from a flat or replayed image.

PAD comes in two styles. Passive PAD works from the normal selfie with no extra steps, which keeps friction low. Active PAD asks the user to move or turn, which adds assurance for higher-risk moments. Independent testing under ISO/IEC 30107-3 tells you which attack types a vendor actually tested against, so read the tested scope rather than reading "Level 2" as blanket protection.

How do attackers bypass the camera entirely?

A more advanced attacker skips the lens. An injection attack feeds prepared video straight into the app through a virtual camera, a hooked API, malware, or a modified copy of your SDK. PAD alone may never fire, because it is watching for artifacts in front of a camera the attacker never used.

Stopping injection takes a different toolkit. Hardened SDKs, device attestation, session cryptography, frame provenance, anti-tamper controls, and server-side anomaly detection all play a part. The core move is to bind the image, the liveness result, and the age request into one transaction, so an attacker cannot assemble a pass from parts captured separately. For a remote adult-content flow, injection resistance matters as much as liveness, because the whole session runs on a device you do not control.

Can a valid age result be replayed?

Even a genuine pass becomes a weapon if it travels. A signed age result or over-18 token that is not tied to a session turns into a bearer token. Copy the response, reuse an old proof, or intercept a callback, and one real success unlocks many fake ones. The fix is to give every result an audience, a one-time value called a nonce, an expiry, and a checked signature, so it works once, for one service, for a short window.

Reusable age credentials raise the stakes, because they are designed to be presented again. They need revocation and freshness on top of anti-replay. Session-based adult access can lean on short-lived proofs. A longer-lived account status is safe only when sharing and recovery are controlled.

What happens when accounts are shared or recovered?

A strong check at signup does not hold if the account changes hands afterward. A verified adult can pass the check and then share the login, hand over the device, or reset the password for a minor. On a dating app or social platform, that is how an underage user ends up inside an adult-verified account without ever facing the check.

Treat recovery with the same suspicion as the original signup. If an over-18 credential can be reset through an email account with weak protection, your age assurance is only as strong as that inbox. Decide what should trigger re-verification, such as a device change, a long gap, suspicious behavior, or access to a higher-risk feature.

Deepfakes are a media class, not one attack

It is tempting to buy one deepfake detector and call it done. A deepfake can be shown on a screen, injected as a virtual camera, used to impersonate a credential holder, or paired with a stolen document. It travels through every attack path above, so there is no single place to catch it. Presentation detection stops the screen version, injection controls stop the virtual-camera version, face matching catches the ones that do not match an enrolled identity, and human or behavioral review catches context that no model sees. A single deepfake score is a feature, not a defense.

Match the controls to the risk

You do not need every control on every user. Over-protecting a low-risk flow adds friction and cost. Under-protecting a high-risk one invites fraud. Scale the controls to what the feature exposes.

The table shows increasing levels of evidence to match rising risk. Test whatever you choose against realistic attacks, and document where it falls short.

Where Youverse stands

Age assurance breaks when "we use facial biometrics" is treated as one proof. Each claim needs its own control. YouLive is our liveness layer. It confirms a real person is present and that the capture reached the app through the real camera, using presentation attack detection and video injection protection that keeps deepfakes out, independently tested to ISO/IEC 30107-3 Level 1 and 2, and storing no biometric templates. YouAge answers the age question from a single selfie, YouID handles document checks when a verified date of birth is needed, and YouAuth keeps a credential tied to the person who created it. The platform still owns the decisions: which features trigger which check, where the threshold sits, and when to re-verify.

See how YouLive holds up against presentation, injection, and deepfake attacks. Book a demo.

FAQ

What is the difference between presentation attack detection and injection detection?
PAD spots a fake held up to the camera, like a printed photo or a screen. Injection detection spots fake video fed straight into the app, past the camera. You need both, because each misses what the other catches.

Does liveness prove who someone is?
No. Liveness shows that a real person was present for a genuine capture. Proving identity takes a face match against a document or another trusted record.

Can an age token be reused by an attacker?
Yes, if it lacks an audience, a nonce, an expiry, a checked signature, or session binding. Reusable credentials also need revocation and holder binding.

Does every age check need a face match?
No. An anonymous, one-time age estimate can skip identity on purpose. Add face matching when the result has to be tied to a verified account or credential holder.

Further reading

• The Age Assurance Guide, the pillar page for the series
• Building an age-assurance waterfall, estimation first, escalate uncertainty
• Challenge 25 is a policy, not a model, how to set an age-estimation threshold