Android Tapjacking Vulnerability

Tapjacking is a UI redress attack targeting Android applications. The name is a portmanteau of"tap" and "hijacking," and it describes precisely what happens: an attacker manipulates what a user taps on their touchscreen,redirecting that input to a hidden application running in the background.

At its core, a tapjacking attack works by placing a non-tappable foreground overlay directly on top of a sensitive UI element in a background application. The user believesthey are interacting with a benign visible interface. In reality, every tapthey register is being delivered to an entirely different application they cannot see.

Unlike many mobile exploits, tapjacking does not require root access, a rooted device, or sophisticated malware infrastructure. This makes it unusually accessible as an attack technique and proportionally dangerous in real-world deployments.

Security Note

Tapjacking  can be used to silently authorize transactions, grant permissions, delete  data, or exfiltrate credentials -- all without a single suspicious visible  action from the attacker's app.

Professional Android Security Testing

Is Your Android Application Vulnerable to Tapjacking?

Redfox Cybersecurity's mobile penetration testing team  specializes in detecting tapjacking, intent hijacking, improper permission  handling, and dozens of other Android-specific vulnerabilities before threat  actors do.

Explore Mobile Pentesting Services  

https://redfoxsec.com/services

How Does a Tapjacking Attack Work?

To understand the mechanics, consider a practical example. Imagine a malicious mobile game that asks the user to tap on moving shapes to score points. The game is fully functional and entertaining. But beneath it, the attacker has arranged for a banking application to run in the background. Every tap the user makes in the game is secretly forwarded to the banking application underneath.

With careful alignment, the attacker can position the game's tap targets to correspond precisely with sensitive controls in the banking app, such as a "ConfirmTransfer" button or a permission grant dialog. The user taps to score a point. The banking app executes a fund transfer.

ATTACK FLOW

Malicious App Launched   -->  SAW Permission Granted   -->  Overlay Created  -->  User  Taps Overlay  -->   Input Delivered to  Background App

The Role of the SYSTEM_ALERT_WINDOW Permission

The attack pivots on a single Android permission: SYSTEM_ALERT_WINDOW (SAW), introduced in API level 1 with Android 1.0. From its initial release through API level 22(Android 5.1 Lollipop), the Android system granted this permission silently,without notifying the user or requiring any explicit consent.

Starting with APIlevel 23 (Android 6.0 Marshmallow), users must explicitly grant this permission through a dedicated management page. However, there is a significant carve-out:applications whose target SDK is set below level 23 continue to receive the permission automatically, without user knowledge. This backward compatibility exception remains a meaningful attack surface in the current Android ecosystem.

 //  Android Manifest permission declaration
<uses-permission  android:name="android.permission.SYSTEM_ALERT_WINDOW" />
 //  Window type used to create a privileged overlay
windowParams.type  = WindowManager.LayoutParams.TYPE_APPLICATION_OVERLAY;
 //  Flag to pass touch events through to the window below
windowParams.flags  = WindowManager.LayoutParams.FLAG_NOT_TOUCHABLE;

Free-Floating Windows and the Window Manager

Once an application holds the SYSTEM_ALERT_WINDOW permission, it can create a TYPE_APPLICATION_OVERLAYwindow using the Android Window Manager. This window type is positioned in thedisplay layer between FIRST_APPLICATION_WINDOW and LAST_APPLICATION_WINDOW,meaning it will appear above standard application activities but below criticalsystem UI elements such as the status bar.

The attackercontrols the overlay's behavior through two primary mechanisms. The typeattribute of the LayoutParams class determines the window's priority in thedisplay layer. The flags attribute determines how touch events areprocessed.

The most relevantflags in a tapjacking context are:

FLAG_NOT_TOUCHABLE:Causes all touch events received by theoverlay to be dispatched directly to the window behind it. The overlay itselfintercepts nothing, but the user cannot see what is behind it.

FLAG_WATCH_OUTSIDE_TOUCH:Notifies the application when a touchevent occurs outside the window's bounds, but withholds the precisecoordinates. This can be used for surveillance without directly handling theevent.

Real-World Tapjacking Attack Scenarios

Unauthorized Financial Transactions

An attacker publishes a free utility application, such as a flashlight or a wallpaper app,that requests the SYSTEM_ALERT_WINDOW permission. Once installed, the appmonitors for the user opening a banking application and deploys a transparent overlay aligned with the "Transfer Funds" or "ConfirmPayment" confirmation button. The user interacts with what appears to betheir normal banking interface, unaware that each confirmation tap is beingregistered through the attacker's overlay.

Silently Granting Dangerous Permissions

Android permission dialogs are prime tapjacking targets. An overlay aligned with the"Allow" button of a sensitive permission request, such as access to the microphone, camera, contacts, or location, can cause the user to grant that permission without ever consciously deciding to do so. The user believes they tapped "Deny." The system recorded "Allow."

Credential Theft via Form Interaction

Password managers and login forms are also viable targets. A carefully constructed overlay cancause a user to submit credentials or authentication tokens to anattacker-controlled destination, or to confirm an OAuth authorization grant fora malicious third-party application.

Identify Vulnerabilities Before  Attackers Do

Request a Mobile Application Security Assessment

Redfox Cybersecurity's offensive security team performs  end-to-end Android application penetration tests, covering tapjacking,  intent-based attacks, insecure data storage, improper certificate validation,  and the full OWASP Mobile Top 10.‍

Schedule a Pentest Consultation  

https://redfoxsec.com/services

How Screen Overlays Enable the Attack

Screen overlays are the translucent UI layers that appear above active applications. They are a legitimate and widely used Android feature. Facebook Messenger's floating conversation bubbles, for example, are implemented as screen overlays.Accessibility services, note-taking apps, and productivity tools rely on this capability extensively.

Android 6.0introduced a security mechanism intended to prevent overlay abuse during sensitive interactions. When an application requests a critical permission, the system is designed to detect whether an active screen overlay might beobscuring the dialog and, if so, block interaction until the overlay is dismissed.

However, the implementation of this protection has historically been inconsistent. The control was not enforced uniformly across all versions and device manufacturers, and targeted applications that did not implement their own touch filtering were left exposed regardless of the platform-level protection status.

How to Prevent Tapjacking in AndroidApplications

Preventing tapjacking requires action at both the application development level and thedevice configuration level. For developers, two primary defenses are availablewithin the Android framework.

XML Attribute Defense

Set  android:filterTouchesWhenObscured="true" on all sensitive View  elements. This causes the view to discard touch events delivered when another  window is obscuring the application.

Programmatic Defense

Override  onFilterTouchEventForSecurity() in custom View subclasses to programmatically  inspect and reject touch events when the view is partially or fully obscured  by another window.

Permission Auditing

Audit all  third-party applications on test devices for the SYSTEM_ALERT_WINDOW  permission. Do not grant this permission to applications from unverified  developers or sources.

Platform Version Control‍

Ensure the  application's target Sdk Version is set to 23 or higher. This removes the  automatic silent grant of SYSTEM_ALERT_WINDOW on Marshmallow and later  devices.
‍

//  XML: Apply to all sensitive UI elements (buttons, confirm dialogs, permission  prompts)
android:filterTouchesWhenObscured="true"
//  Java: Programmatic equivalent in a custom View
@Override
public  boolean onFilterTouchEventForSecurity(MotionEvent event)
if ((event.getFlags() &  MotionEvent.FLAG_WINDOW_IS_OBSCURED) != 0)
// Touch event delivered while  obscured -- discard it
return false
}
return  super.onFilterTouchEventForSecurity(event)
}

Recommendations for End Users

Users can substantially reduce their tapjacking exposure by following a few discipline-based practices. Only download applications from reputable developers with established publication histories and verified reviews. Treatany application requesting the SYSTEM_ALERT_WINDOW ("Draw over other apps") permission with heightened scrutiny. This permission is legitimately required by a narrow category of applications; most consumer appshave no genuine need for it.

Keeping the device updated to Android 6.0 or later ensures the mandatory permission grant dialog is in place for new SYSTEM_ALERT_WINDOW requests. Users should alsoperiodically review which applications on their device currently hold this permission via Settings and revoke it for any application that does not clearly require it.

Why Tapjacking Is Frequently Missed in Security Assessments

Tapjacking is an application-layer vulnerability that sits at the intersection of platformbehavior and individual application configuration. Automated scanners often fail to flag it because the vulnerability is not a code flaw in the traditional sense. It is an omission: a missing attribute, a missing method override, or anunreviewed permission posture.

Manual penetration testing is the reliable mechanism for identifying tapjacking exposure. A skilled assessor will construct a test overlay tailored to the specific application's UI, verify whether touch events are accepted whenobscured, and document the precise attack path an adversary could exploit. This is exactly the methodology Redfox Cybersecurity applies in Android mobile security engagements.
 
‍What Automated Tools Miss

Static  analysis tools rarely flag the absence of filterTouchesWhenObscured. Dynamic  analysis requires a deliberately constructed overlay attack against the  target application's specific UI. Without manual testing by a skilled  assessor, tapjacking vulnerabilities routinely ship to production.

Work With Redfox Cybersecurity

Your Android Application Deserves a Real Security  Assessment

Redfox Cybersecurity is a global network of expert security  consultants delivering data-driven, research-based, and manual penetration  testing. Our offensive security specialists have years of experience securing  Android applications across financial services, healthcare, and enterprise  sectors.

View Redfox Pentesting Services  

https://redfoxsec.com/services

Frequently Asked Questions About Android Tapjacking

What is Android tapjacking?

Android tapjacking is a UI redress attack where a malicious application places a transparent or opaque overlay on top of a legitimate application's sensitive UI elements, causing the user's touch inputs to be delivered to the hidden application instead of the visible one.

Does tapjacking require special permissions?

Yes. Tapjacking leverages the SYSTEM_ALERT_WINDOW permission to create a privileged overlay window. On Android 6.0 and above, users must explicitly grant this permission. However, applications targeting SDK versions below 23 continue to receive it automatically.

How can developers protect their Android apps from tapjacking?

Developers should set android:filterTouchesWhenObscured="true" on all sensitive UI components and implement the onFilterTouchEventForSecurity() method to reject touch events delivered while the view is obscured by another window.

Can tapjacking be used to steal banking credentials?

Yes. Tapjacking can be used to cause users to unknowinglyconfirm financial transactions, grant sensitive permissions, or submitcredentials to attacker-controlled destinations -- all without any visibleindication that something is wrong.

Is tapjacking detectable by automated security scanners?

Automated tools frequently miss tapjacking because the vulnerability is a configuration omission rather than a code defect. Manualpenetration testing with a purpose-built overlay against the targetapplication's specific UI is the reliable detection method.

Final Takeaway

Tapjacking is a quiet, underrated, and consistently underreported vulnerability class in the Android security landscape. It does not announce itself. It does not requireobvious malware behavior. It exploits a legitimate platform feature, theoverlay window system, and turns it into a silent input hijacker that operates entirely within the bounds of normal application behavior.

For developers,the fix is a few lines of code and a systematic review of every sensitive Viewin the application. For organizations, the assurance that those fixes are inplace requires a skilled manual assessor who can construct the attack and verify the defense.

Redfox Cybersecurity has built its practice on exactly this kind of rigorous, attacker-mindset testing. Whether your concern is tapjacking, SSL pinningbypass, insecure inter-process communication, or the full OWASP Mobile Top 10,our team brings the technical depth to find what automated tools miss and the communication skills to help your engineering team close those gaps permanently.