Skip to content
Request a scoping call

Penetration testing

iOS and Android Penetration Testing

iOS and Android testing that treats the app as untrusted, because in an attacker's hands it is.

Request a scoping call See what you receive

Engagements from $5,000 CAD. Free scoping, a fixed price in writing before any work begins, and one retest included.

At a glance

Is this the right test?

Best when
The app handles accounts, payments or personal data, on one platform or both.
Covers
Local storage, transport security, session handling, deep links and other platform interaction, code protection, and the APIs behind the app.
You learn
What the app gives away on a device an attacker controls, and what the backend accepts from a modified client.

Before we start

What we need from you

Scoping settles the details. These are the things that usually decide whether testing can start on the agreed date.

  • Builds for each platform in scope: a debuggable or instrumentable build and the release build.
  • Test accounts, and a way for our devices to reach the backend.
  • The supported OS versions, and whether rooted or jailbroken devices are in or out of scope.
  • API documentation, where it exists.

Deliverables

What lands in your inbox

  • Executive summary

    A plain-language account of the risk position across the platforms and builds in scope, written for a non-technical reader.

  • Overall security grade

    A single grade derived from the most severe confirmed finding, using the thresholds set out in the report.

  • Detailed technical findings

    Every finding with CVSS vector, CWE classification, affected platform and build, and reproduction steps.

  • Proof-of-concept evidence

    Intercepted traffic, extracted artefacts and device screenshots proving each finding is real.

  • Remediation recommendations

    Written against the platform in question, distinguishing what belongs in the app from what belongs in the API.

  • Retest summary

    Issued after remediation against a fresh build, confirming what is closed.

See a redacted excerpt from a real finding, and what the full report adds.

Why it matters

What this protects you from

  • The binary is in their hands

    Anyone can download your app, unpack it, and read it. Server-side authorization cannot rely on restrictions the client enforces.

  • Secrets shipped in the bundle

    Credentials hardcoded at build time are recoverable from the package. Endpoint URLs and public identifiers are not secrets, but they map the backend for whoever reads them.

  • 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. The most serious findings are often 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. 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. Static analysis

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

  3. Dynamic analysis

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

  4. Targeted exploitation

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

  5. Reporting and remediation

    Written findings with reproduction steps, device context, evidence and platform-specific remediation guidance, ranked by exploitability, business impact and what has to be fixed first.

  6. Retest

    After remediation we retest the reported findings on a fresh build, one round, requested within 60 days of the report, 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.

Also worth reading

Where to go next

Find out what an attacker would find first.

Request a scoping call Request a sample report