Mobile Security Testing

Why it matters

The company does not control the phone. It can be lost, rooted (unlocked for full system access) or restored from a backup, it joins public Wi-Fi, and anyone can take the app package apart. Whatever the app stores, sends or accepts from other apps is exposed, and one leaked token can mean a taken-over account.

Most first-line checks need no hacking skills, and knowing the platform rules prevents false reports: an app that refuses to talk through your proxy is often doing exactly what it should.

MASVS control groups

MASVS sorts its controls into eight control groups, each named with a MASVS- prefix; MASTG describes how to test them on Android and iOS.

This lesson tests the storage, network and platform groups, where a tester's ordinary tools find real defects. All eight:

• MASVS-STORAGE: sensitive data on the device is protected and does not leak.
• MASVS-CRYPTO: strong algorithms, and no keys hard-coded in the app.
• MASVS-AUTH: login, sessions and authorisation enforced by the back end; local checks such as biometrics done securely.
• MASVS-NETWORK: TLS with proper certificate validation, and pinning where the risk calls for it.
• MASVS-PLATFORM: safe use of links, components, WebViews and the screen.
• MASVS-CODE: untrusted input is validated; no components with known vulnerabilities.
• MASVS-RESILIENCE: resistance to reverse engineering and tampering where the risk requires it.
• MASVS-PRIVACY: only the data the app needs, visible to and controlled by the user.

Local storage: what stays on the device

An app keeps data in its sandbox: preference files in shared_prefs, SQLite databases and files on Android; UserDefaults, files and databases on iOS. The sandbox keeps other apps out, but not someone with a rooted phone, a backup or a debuggable build (a debug build, which lets tools such as run-as reach the app's files; release builds are not debuggable). Data also leaks to logs, the clipboard and the app-switcher screenshot.

MASVS-STORAGE is simple to test: sensitive data is stored only when needed, secrets are kept in the iOS Keychain or encrypted with a key held in the Android Keystore (the platforms' protected stores), logs hold nothing sensitive, and logout removes the session's data. Encoding is not encryption: a Base64 string or a signed JWT in a file is readable by anyone who gets the file. On an Android QA build, look yourself:

# Debuggable QA build, on a test phone or emulator you may use
adb shell run-as com.example.shop ls shared_prefs databases files
adb shell run-as com.example.shop cat shared_prefs/session.xml
#   <string name="refresh_token">eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOi...</string>
#   ^ a finding: a token in plain text

adb logcat -d | grep -i -E "password|token|bearer|otp"

# Release build: run-as must fail, because the build is not debuggable
adb shell run-as com.example.shop ls

Try it: Base64 Decoder Try it: JWT Decoder Try it: JWT Expiration Checker

Worked example: reading an Android app's HTTPS traffic

You have written permission to test your team's shopping app against api.staging.shop.example. An intercepting proxy is a tool that sits between the app and the server and shows every request and response; the lesson on intercepting proxies shows the set-up in depth. Its scope is the set of hosts you are authorised to test, so you put only that host in scope. Its history lists every request it captured, so you can find one later, attach it as evidence or replay it (send it to the server again). The proxy runs on your laptop, listening on the laptop's Wi-Fi address, for example 192.168.1.20:8080. To read HTTPS, the proxy ends the app's TLS connection itself and presents a certificate for the host signed by its own certificate authority (CA). So on a dedicated test phone you set that address as the Wi-Fi proxy and install the proxy's CA certificate as a user certificate.

The app now fails to connect and the proxy logs TLS handshake errors. That is Android working as designed: since Android 7.0 (API level 24), apps that target that level or higher trust only system CAs by default, not CAs a user added. The safe opt-in, shown below, is a debug-overrides block in the network security configuration: it applies only to a debuggable build, so the QA build trusts your proxy CA and the release build keeps the default. With the traffic readable, check:

• Every request uses HTTPS, images and SDKs included. Apps that target Android 9 (API level 28) or higher block plain HTTP by default, so a working http:// call usually means someone allowed cleartext for that host: report it.
• Tokens travel in the Authorization header, never in a URL, where servers log them.
• After logout, replaying a request with the old token returns 401 Unauthorized.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <debug-overrides>          <!-- applies only when the app is debuggable -->
    <trust-anchors>
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

<!-- AndroidManifest.xml -->
<application android:networkSecurityConfig="@xml/network_security_config" ...>

Try it: HTTP Headers Parser Try it: API Authentication Tester

Certificate pinning is expected behaviour

Certificate pinning, which MASVS calls identity pinning, means the app accepts only a known certificate, public key or CA for its own API hosts. It protects users from a malicious or unwanted CA on the phone, and it also blocks your proxy: the handshake fails. On a release build that is a pass, so "the app does not work through my proxy" is a false report.

Whether to pin is a risk decision the team records. When the app pins, test the behaviour, not a bypass:

• Through the proxy, the pinned build refuses the connection with a clear error, no crash and no retry over plain HTTP; without the proxy it works.
• An Android release build rejects a user CA anyway, so that failure alone does not prove pinning; ask for a test build that trusts user CAs but keeps the pins.
• Traffic for functional checks comes from the QA build: by default, Android skips the pins in the network security configuration for CAs in debug-overrides. Pinning written in the app's code needs its own debug switch; agree on it with the developers. Bypassing pinning in a release build is specialist work.
• Ask how pins are rotated: Android's documentation recommends always including a backup key, or a server key change cuts off every installed copy until an app update ships.

Platform interaction: links, components, WebViews and the screen

MASVS-PLATFORM covers what the app exchanges with the operating system and other apps. Treat every entry point another app or web page can reach as untrusted input; the commands below open a deep link the way another app would.

• Deep links: any app can open shop://orders/1043 with any value. A protected screen asks for login first, and the server still refuses another user's order. Android App Links and iOS Universal Links are verified against the app's domain; a custom scheme such as shop:// is not, and another app can register the same scheme and receive the link, so it must never carry a secret such as a token.
• Exported components: Android activities, services, receivers and content providers are exported only when other apps need them, and then check what they receive.
• WebViews load only the app's own or allow-listed pages, never a URL taken from a link parameter.
• The screen: sensitive screens are hidden in the app-switcher preview, and password fields are masked.

# Android test device: open a deep link the way another app would
adb shell am start -W -a android.intent.action.VIEW \
  -d "shop://orders/1043" com.example.shop

# iOS simulator
xcrun simctl openurl booted "shop://orders/1043"

Frequently asked questions

References

• OWASP Mobile Application Security Verification Standard (MASVS)OWASP FoundationOWASP's security requirements for mobile apps, grouped into control areas such as storage, cryptography, authentication, network and platform interaction.
• OWASP Mobile Application Security Testing Guide (MASTG)OWASP FoundationThe testing manual that goes with MASVS: techniques and test cases for verifying mobile app security.
• About App LinksAndroid Developers (Google)Android App Links: deep links to your own website that the system verifies through a Digital Asset Links file (assetlinks.json), so they open the app directly.
• Certified Tester Mobile Application Testing (CT-MAT)ISTQB · 2019ISTQB's specialist syllabus on mobile testing: app types, device and platform challenges, test types and tools.