Tapjacking is the mobile cousin of clickjacking: a malicious app draws something on top of your app so the user thinks they are tapping one thing while actually tapping another. The overlay might hide a real button, a permission grant, or a confirmation, and the user's tap goes through to your app underneath. Android gives you a simple defense for sensitive screens, discarding touches when your view is covered, and the platform has tightened overlay behavior over time. Here is what tapjacking is, how an overlay attack works, and how to protect your app.
Short answer
Tapjacking is an attack where a malicious app draws an overlay on top of your app, using the draw-over-other-apps capability, so the user taps something they cannot see, such as a hidden confirmation or permission grant, while believing they are tapping the overlay. Per Android's guidance, the defense for sensitive views is to discard touches received while the view is obscured, by setting filterTouchesWhenObscured to true, so a tap delivered through an overlay is ignored. Apply this to sensitive UI like login, payment, and confirmation screens, and rely on the platform's own restrictions on overlays during system dialogs. It turns a tap through an overlay into a tap your app refuses to act on.
What you should know
- Tapjacking uses an overlay: a malicious app draws over yours.
- The user taps something hidden: a confirmation, grant, or button they cannot see.
- filterTouchesWhenObscured is the defense: discard touches while obscured.
- Apply it to sensitive views: login, payment, confirmations, permission grants.
- The platform adds restrictions: newer Android limits overlays during system dialogs.
What is tapjacking?
It is tricking the user into tapping your app through a deceptive overlay. A malicious app that can draw over other apps places a window on top of yours, presenting a harmless-looking interface, a game, an ad, a fake button, while your real interface sits underneath. The overlay is arranged so that when the user taps what they see, the touch passes through to a control in your app they did not intend to activate, such as a confirmation, a permission grant, or a sensitive action. Because the user never sees your underlying button, they are deceived into performing it. The capability to draw over other apps is what enables this, and while it has legitimate uses, it is also the mechanism behind tapjacking, which is why protecting sensitive interactions matters.
How does an overlay attack work?
By covering your UI and letting the tap pass through. The table breaks down the pattern.
| Step | What happens |
|---|---|
| Overlay is drawn | A malicious app draws a window over your app |
| User sees the overlay | The decoy interface, not your real control |
| User taps the decoy | Believing they are interacting with the overlay |
| Touch reaches your app | The hidden control underneath is activated |
The deception works because the user acts on what they see, while the consequence happens in your app beneath. The classic targets are actions where a single tap matters, confirming a payment, granting a permission, deleting data, accepting terms, since the attacker only needs the user to tap once in the right place. The defense is to make your app refuse a touch it received while something was drawn over it.
How do you defend against tapjacking?
Discard obscured touches on your sensitive views. Android lets a view ignore touch events that are delivered while another window is on top of it: set filterTouchesWhenObscured to true, in the layout or in code, on the views handling sensitive actions, and the system discards a touch when the view is obscured, so a tap delivered through an overlay does nothing. Apply this to the screens and controls that matter, sign-in, payment, confirmations, granting permissions, where a single deceptive tap would be damaging, rather than every view, since it is the sensitive interactions that need it. The platform also helps: newer Android versions restrict overlays in sensitive contexts, such as hiding system permission dialogs when an overlay is present. So combine your own touch filtering on sensitive UI with the platform protections, and treat any single-tap consequential action as something to guard.
What to watch out for
The first trap is leaving sensitive actions, payments, permission grants, confirmations, without obscured-touch filtering, so a tapjacking overlay can drive them; enable filterTouchesWhenObscured there. The second is assuming the platform handles all of it, when your own sensitive views still benefit from the filter. The third is over-applying it everywhere, when the priority is the consequential, single-tap actions. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and assesses platform-interaction protections, which complements reviewing whether your sensitive screens filter obscured touches. The touch-filtering setting you apply on your views.
What to take away
- Tapjacking uses an overlay drawn over your app so the user taps a hidden control, like a confirmation or permission grant, while believing they are tapping the overlay.
- The defense is to discard touches received while the view is obscured, by setting
filterTouchesWhenObscuredto true on sensitive views. - Apply it to consequential single-tap actions, login, payment, confirmations, permission grants, and rely on the platform's restrictions on overlays during system dialogs.
- Use a pre-submission scan such as PTKD.com to assess your platform-interaction protections alongside enabling obscured-touch filtering on sensitive UI.
