Observing and changing an app while it runs is often easier than reading its code. Anti-debugging and anti-instrumentation checks raise the cost, with the same limit as other client-side checks: the device belongs to the attacker.
- Detect debuggers and instrumentation where the threat model justifies it, and respond with server-side consequences.
- Weigh false positives on legitimate devices and the support cost before shipping such checks.
MASTG tests in the local projects
Neither local project runs a MASTG test for MASVS-RESILIENCE-4. The guides below explain the platform mechanisms, and the control’s page on mas.owasp.org links the MASTG tests and weaknesses OWASP maps to it.
Guides on this site
Practice
- Keep an iOS app's storage, links and web bridge in bounds · Local project
- Repair an Android app's links, components, network policy and storage · Local project
Gaps on this site
The mobile trust-boundaries guide weighs anti-debugging against its costs. No guide here shows how to implement or test anti-debugging or instrumentation detection.
References
- MASVS-RESILIENCE-4 (OWASP MASVS v2.1.0)
- MASVS-RESILIENCE: Resilience Against Reverse Engineering and Tampering (OWASP MASVS v2.1.0)
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.
Control statements are quoted from OWASP MASVS v2.1.0, licensed CC BY-SA 4.0; the rest is this site's summary. MASTG tests are those the iOS and Android projects here run, with their titles from mas.owasp.org. License.