Mobile App Security: Understanding OWASP MAS Testing
A mobile app runs on a device you do not control, in the hands of a user who might be an attacker. That changes the testing model completely: you assume the phone is rooted, the traffic is intercepted, and the app binary is being pulled apart. The OWASP Mobile Application Security project (MASVS and MASTG) is the map we follow. Here is what that looks like in practice.
Start with local storage and secrets
The first question is what the app leaves lying around on the device. On Android we go through SharedPreferences, internal and external storage, WebView caches, and SQLite databases; on iOS, the Keychain, plists, and user defaults. A rooted device and a few commands surface most of it:
bash
# Pull an Android app's private data directory for review (test device you own)
adb shell run-as com.example.app tar -cf - /data/data/com.example.app | tar -xf - -C ./app-data-review
# Grep the extracted files for tokens, keys, and passwords
grep -rniE 'token|secret|password|api[_-]?key|BEGIN .* PRIVATE KEY' ./app-data-reviewAssume the device is hostile
Next we test runtime integrity. Root and jailbreak detection, SSL pinning, and anti-tampering should slow an attacker down, but the app must never rely on them as its only defense. We use Frida and Objection to instrument a running app and confirm that the server, not the client, enforces the important rules.
bash
# Inspect an app at runtime and test SSL pinning bypass resistance (authorized testing)
objection -g com.example.app explore
# within objection: android sslpinning disableThe key principle: every check the app performs on the device can be bypassed by a determined attacker with a rooted phone. Client-side controls raise the cost of an attack; the server is what actually has to enforce authorization, ownership, and limits.
The API is the real target
Most serious mobile findings are not on the phone at all, they are in the API behind it. If the backend assumes the app enforces ownership, an attacker who swaps a token or an object ID gets someone else's data. That is broken object level authorization, and it is as common in mobile backends as it is in web APIs, we cover it in depth in why BOLA remains the number one risk.
Transport and sessions
TLS should be mandatory with modern ciphers and no cleartext fallback. Access tokens should be short-lived, refresh tokens should rotate, and biometric flows need server-side re-verification for sensitive actions so a local bypass does not equal account takeover.
Shipping an iOS or Android app that handles anything sensitive? Our mobile application security testing follows OWASP MAS end to end, app and backend. Get in touch to scope it.
