FLAG_SECURE bypass techniques on Android, understood defensively, all share one requirement: a device the attacker controls, usually rooted. On such a device, a runtime instrumentation framework like Frida can hook and disable the code enforcing FLAG_SECURE, and Magisk modules exist that turn off the secure-flag enforcement system-wide, so screenshots and recording of protected windows work. On a normal, unmodified device, none of this applies and FLAG_SECURE blocks capture as intended. The defensive takeaway is that FLAG_SECURE is effective against casual capture but not against a determined attacker on their own rooted device, so treat it as one layer and keep sensitive logic and secrets off the client.
Short answer
FLAG_SECURE can be bypassed only on a device the attacker controls, so understand the threat model rather than expecting it to be absolute. Per the Android WindowManager reference, the flag blocks screenshots and capture on normal devices. On a rooted device, Frida can hook the enforcement to disable it, and Magisk modules can turn off secure-flag enforcement system-wide, both of which require root and do not apply to a normal device. Test only your own app on an isolated rooted device, in line with OWASP MASTG resilience guidance. The remediation is to treat FLAG_SECURE as one layer, keep secrets and trusted logic off the client, and minimize sensitive on-screen data.
FLAG_SECURE's threat model
FLAG_SECURE is designed to stop operating-system-level screen capture, screenshots, recording, and casting, of a window it is set on, and against a normal, unmodified device it does that well. The threat it is built for is casual or opportunistic capture on a device that behaves as the operating system intends, and within that threat model it is effective and worth using.
The bypass techniques all step outside that model, onto a device the attacker fully controls. Once someone has root or a modified system, they can change how the device enforces the flag, which is not a weakness in FLAG_SECURE so much as the reality that a client-side control cannot bind a device its owner has full power over. So the accurate framing is that FLAG_SECURE protects against the threat it targets, and the bypasses live in a different threat model, a controlled device, that it was never able to cover.
Can Frida bypass FLAG_SECURE?
On a rooted device, yes. Frida is a runtime instrumentation framework that, on a device the tester or attacker controls, can attach to a running app and change the behavior of specific methods. Applied to FLAG_SECURE, it can hook the call that sets the secure flag, or the enforcement around it, so the window is no longer treated as secure and can be captured. This is the same class of runtime bypass used against other client-side controls.
The important qualifier is that Frida requires that level of control. It needs the ability to instrument the process, which on a normal device it does not have, so a Frida-based bypass is a controlled-device attack, not something that works against an ordinary user. For a defender, the lesson is that a single client-side check enforcing the flag is defeatable by instrumentation, which is why you do not rely on it alone for data that must resist a determined attacker.
Magisk modules that disable the secure flag
Magisk is a common rooting solution, and there are Magisk modules whose purpose is to disable FLAG_SECURE enforcement across the whole system on a rooted device. Where a Frida hook targets one app at runtime, such a module changes the device so that the secure flag is ignored for apps generally, allowing screenshots and recording of windows that would otherwise be protected. It is a system-level version of the same bypass.
Like the Frida approach, this requires root and a modified device, so it does not affect a normal user. The existence of these modules underlines the point that on a device the owner has fully modified, the enforcement of a client-side flag is under their control, not yours. So a Magisk module disabling the secure flag is possible on a controlled device and irrelevant on an unmodified one, which is exactly the boundary a defender designs around.
Why these require a controlled device
Every FLAG_SECURE bypass technique depends on the attacker controlling the device, because the flag is enforced by the operating system on that device. To change that enforcement, whether by instrumenting the app with Frida or altering the system with a Magisk module, the attacker needs root or a modified system, which is control an ordinary user does not have over their own phone in the default state. This is why the bypasses are real but bounded.
The consequence is a clear line. On a normal device, FLAG_SECURE holds and blocks capture; on a device the attacker has rooted or modified, it can be turned off. So the flag genuinely protects against the common case of capture on unmodified devices, and it cannot protect against someone who has taken full control of the device, because no client-side control can. Designing with that line in mind is what turns knowledge of the bypasses into a sound security posture.
What this means for your app
For your app, this means treating FLAG_SECURE as a valuable layer against casual capture, not as protection for anything that must resist a determined attacker. Set it on every sensitive window so ordinary screenshots and recordings are blocked, but do not assume it protects a secret or a high-value screen against someone on their own rooted device. Anything that truly must not be exposed should not depend on a client-side flag.
The durable protections sit elsewhere. Keep secrets and trusted logic on your server, where the attacker has no control, and minimize how much sensitive data appears on screen at all, so a bypassed flag reveals as little as possible. You can add root or tamper detection to raise the effort, but those are also client-side controls a determined attacker can bypass, so they are speed bumps, not walls. FLAG_SECURE belongs in that layered design as one useful control.
Testing responsibly on your own app
Test only your own app, on an isolated rooted device or emulator you own, with the goal of understanding your control's resilience. Confirm what a bypass exposes, whether any sensitive action or data is reachable once the flag is disabled, and whether you are placing more trust in the flag than a controlled device can be given. Each finding points to a hardening step, in line with OWASP MASTG resilience testing of your own software.
Keep the work scoped and remediation-focused, never applied to software or devices you do not own. The purpose is to see your app the way an attacker on a controlled device would, so you can decide what to move server-side and what to remove from the screen, not to produce a reusable bypass. That is how authorized testing turns knowledge of these techniques into a stronger app.
Bypass techniques at a glance
Seeing the techniques and their requirements together clarifies the boundary. The table below summarizes them.
| Technique | What it requires | Works on a normal device? |
|---|---|---|
| Frida runtime hook | A rooted device and instrumentation | No |
| Magisk module disabling the flag | A rooted device and the module | No |
| A custom ROM ignoring the flag | A modified system | No |
| Physical camera on another device | Nothing, outside any software control | Not applicable |
| Ordinary screenshot or recording | A normal device | No, FLAG_SECURE blocks it |
Read the table as the boundary of FLAG_SECURE. The software bypasses all require a controlled, modified device, while on a normal device the flag blocks capture, and only an out-of-band camera is entirely outside its scope.
Hardening checklist
A short checklist turns the threat model into fixes. The list below covers the measures that matter.
| Check | Action | Done? |
|---|---|---|
| Set FLAG_SECURE | Apply it to every sensitive window | [ ] |
| Do not rely on it alone | Keep secrets and trusted logic server-side | [ ] |
| Minimize on-screen data | Reduce sensitive information shown on screen | [ ] |
| Test your own app | Assess resilience on an isolated rooted device | [ ] |
| Design for a controlled device | Assume a determined attacker can disable it | [ ] |
The two that matter most are keeping secrets and trusted logic server-side and minimizing sensitive on-screen data, since those hold even when the flag is bypassed. FLAG_SECURE and any tamper detection raise the cost for an attacker, but the durable protection is not on the client.
What to take away
- Every FLAG_SECURE bypass technique requires a device the attacker controls, usually rooted, so the flag holds on normal devices.
- Frida can hook and disable the flag's enforcement at runtime, but only on a device it can instrument, which needs root.
- Magisk modules can disable secure-flag enforcement system-wide, again only on a rooted, modified device.
- Treat FLAG_SECURE as one layer against casual capture, keep secrets and trusted logic server-side, and minimize sensitive on-screen data.
- Test only your own app on an isolated device, and scan with PTKD.com to find where screenshot protection is missing or over-trusted.
