A common example of SYSTEM_ALERT_WINDOW is an Android app that draws a floating overlay on top of other apps, such as chat bubbles, screen filters, or call controls. Attackers abuse the permission for phishing overlays, credential capture, and click interception. Defenders should review which apps hold it, why they need it, and whether overlays are shown unexpectedly.
What does SYSTEM_ALERT_WINDOW usually look like in real apps?
On Android, this permission is usually visible in apps that need to stay on screen while you use something else. The most familiar examples are chat bubbles, screen dimming or color filters, and call or recorder controls that float above other apps. The permission is powerful because the overlay can sit on top of the interface the user is trying to trust.
That is why the same feature can be benign in one app and dangerous in another. A floating control that helps with multitasking is normal; an overlay that appears unexpectedly, covers login fields, or closely mimics a system prompt is a warning sign.
Why do overlays create security risk?
Overlays can be abused to hide the real app underneath, steer taps to the wrong control, or imitate a trusted screen at the exact moment a user enters secrets. That makes the permission attractive for phishing overlays, credential capture, and click interception. NHI Management Group’s Mobile Malware Guide covers the mobile attack patterns behind overlay abuse and why they are common in Android malware.
Because the overlay runs in the foreground of the user experience, the attack often succeeds without needing to compromise the underlying app first. The malicious app only needs a believable prompt, a convincing visual copy, and a moment when the user expects a login or confirmation step.
How should defenders review apps that request it?
Review the permission in context, not in isolation. Ask whether the app’s function genuinely needs an always-on-top surface, whether the overlay is core to the product, and whether the app behaves as expected when it is backgrounded or newly installed. A utility that only needs a temporary floating control is a different case from an app that requests broad overlay capability with no clear user benefit.
It also helps to compare the permission against other signals. Unexpected installation source, unusual accessibility use, aggressive prompting, or a mismatch between the app’s stated purpose and its overlay behavior should raise scrutiny. If the overlay is central to the workflow, ensure users can recognize the trusted screen and exit the feature easily.
Risk and Threat Considerations
Overlay abuse is risky because it exploits user trust at the point where credentials, approvals, or one-time codes are most likely to be entered. The interface can look legitimate even when the underlying app is not, so users may hand secrets to a fake surface or confirm an action they did not intend.
Failure mechanism: A malicious app gains overlay permission, places a convincing screen above a trusted app, and intercepts taps or input before the user notices the mismatch.
Impact: Attackers can capture passwords, OTPs, payment approvals, or other sensitive actions, and they may use that access to extend compromise beyond the first device interaction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Overlay permissions should be limited to apps that truly need them. |
| Recommendation — Restrict SYSTEM_ALERT_WINDOW to apps with a documented need and remove unnecessary overlay access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Apps with overlay capability need controlled, reviewed access to sensitive UI paths. |
| Recommendation — Review and revoke overlay-capable app access that is not explicitly required. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | The risk is unauthorized execution of a high-trust UI function over protected flows. |
| Recommendation — Treat overlay-triggered actions as privileged flows and block untrusted app access to them. | ||
| MITRE ATT&CK | T1113 — Screen Capture | Overlay abuse commonly supports visual interception of sensitive user input and screens. |
| Recommendation — Hunt for apps that visually intercept or obscure sensitive screens during credential entry. | ||
Practitioner Guidance
What to verify: Confirm that each app holding the permission has a clear business need for persistent overlays, and test whether the overlay appears only in the expected user journey. If the app can function without that surface, treat the permission as unnecessary exposure.
Decision rule: If the overlay is not essential to the app’s core function, remove or disable it. If it is essential, constrain when it appears, make the visual identity obvious, and require extra scrutiny for any screen that asks for credentials or approval.
Practitioner takeaway: The important question is not whether an app can draw over other apps, but whether that capability is tightly justified, clearly visible, and incapable of impersonating a trusted flow.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org