Root and jailbreak detection: myths and facts

Root and jailbreak detection tries to spot a device whose operating system has been modified. It can help your app react to risk, but it is a speed bump, not a lock. Treat a failed check as a signal, never as the only protection for sensitive data.

What the standard asks

MASVS has a group called RESILIENCE with four controls. RESILIENCE-1 says the app validates the integrity of the platform, because "trusting the platform is essential for many of the MASVS controls", such as secure storage, biometrics and sandboxing. RESILIENCE-2 covers anti-tampering, RESILIENCE-3 anti-static analysis and RESILIENCE-4 anti-dynamic analysis, including preventing dynamic instrumentation.

The OWASP cheat sheet's integrity advice is to verify app integrity at runtime, detect hooking, injection, emulators and rooted or jailbroken devices, and define how the app responds to tampering, such as limiting features.

Myth versus fact

Myth: detection makes a rooted phone safe to support. Fact: detection reports a guess about the environment. The code doing the check runs on a device the user controls, so a determined attacker can try to alter it. That is exactly what RESILIENCE-3 and RESILIENCE-4 try to make harder, and the standard's wording is "as difficult as possible", not impossible.

Myth: every rooted device is hostile. Fact: many people root phones for legitimate reasons. Blocking them outright may cost you customers with little security gain. Decide per feature.

Myth: if the check passes, the device is clean. Fact: a pass means your checks found nothing. It does not prove the platform is intact.

Myth: resilience controls replace secure design. Fact: they sit on top of it. If your server trusts the client, hardening the client will not fix that.

Fact: it matters more for some apps. Apps where tampering has a direct cost, such as payments, games with in-app purchases and apps that unlock paid features locally, are the natural fit. The RESILIENCE-2 description mentions running a modified version to cheat or to enable premium features without paying, and uploading backdoored copies to third-party stores.

A sensible policy

1. Decide which features are sensitive: login, payments, viewing records.
2. For those, run integrity checks and respond in proportion. Options: warn, limit features, require extra authentication, or block.
3. Send the signal to your backend with the request, so the server can factor it into risk decisions.
4. Keep server-side enforcement as the real gate.
5. For low-risk apps, skip heavy resilience work and record why in your MASVS review.

Keep it honest

Be clear with your own team about the goal: raise the effort and the cost for an attacker, and detect common tampering. Avoid promising customers that the app "cannot be reversed" or that it is "unhackable".

Also test the false positive rate. A check that locks out honest users on a new OS release is a support cost with no benefit. Re-run the checks when the platform ships a major version.

Quick check

Sources

• MASVS-RESILIENCE-1
• MASVS-RESILIENCE-2
• MASVS-RESILIENCE-3
• MASVS-RESILIENCE-4
• OWASP Mobile Application Security Cheat Sheet

Last reviewed: 19 October 2026.