Mobile Application Testing

Why it matters

What this protects you from

• The binary is in their hands

  Anyone can download your app, unpack it, and read it. Controls that live only in the client are not controls.

• Secrets shipped in the bundle

  API keys, tokens and endpoint URLs hardcoded at build time are recoverable from the package within minutes.

• Data left on the device

  Credentials, tokens and personal data written to unprotected storage survive logout and are readable on a compromised handset.

• The backend is the real target

  A mobile app is a client for your API. Most serious findings are behind it, not in it.

Coverage

What we test

• Local data storage

  Keychain and Keystore usage, shared preferences, SQLite databases, caches, logs and backup artefacts.

• Transport security

  TLS configuration, certificate validation and pinning, and whether pinning can be bypassed on a rooted or jailbroken device.

• Authentication and session handling

  Token storage and lifetime, biometric gating, session persistence, and behaviour after logout or credential change.

• Platform interaction

  Deep links and URL schemes, exported activities and intents, IPC surfaces, clipboard and screenshot exposure.

• Code protection and reverse engineering

  Obfuscation, anti-tamper and root or jailbreak detection, assessed for what they actually delay rather than what they claim.

• Backend API trust

  Every endpoint the app calls, tested directly with the client removed from the path.

Approach

Three ways to run it

• Black box

  The published build and nothing else. Mirrors an attacker who downloaded your app from the store this morning.

• Grey box

  Test accounts across each role, plus a build we can instrument. The usual choice for a first mobile assessment.

• White box

  Source code alongside the build. Lets us trace how secrets are handled and where platform storage is actually used.

Process

How the engagement runs

1. 01

   Scoping and threat alignment

   We agree platforms, builds, roles, test devices and exclusions in writing, then map what the app exposes and what it talks to.

2. 02

   Static analysis

   The package is unpacked and reviewed for hardcoded secrets, insecure storage calls, weak cryptography and dangerous configuration.

3. 03

   Dynamic analysis

   The app is run on instrumented devices, with traffic intercepted and runtime behaviour observed against live backends.

4. 04

   Targeted exploitation

   Confirmed exploitation of what static and dynamic testing surfaced, including the API endpoints behind the app.

5. 05

   Reporting and remediation

   Written findings with reproduction steps, device context, evidence and platform-specific remediation guidance.

6. 06

   Retest

   After remediation we retest the affected flows on a fresh build and issue a retest summary.

Standards

What we test against

OWASP MASVS

Verification requirements for mobile, so coverage is measured against a published standard rather than improvised per platform.

OWASP MASTG

Concrete iOS and Android test cases, which keeps results comparable across builds and across engagements.

OWASP API Security Top 10

Applied to the backend the app depends on, because that is where the highest-impact mobile findings usually live.

NIST SP 800-115

Overall assessment structure, which is what procurement teams expect to see referenced.