Application Security

Mobile testing that assumes the device is hostile.

Once your application is installed, it is running on hardware controlled by someone else. Assume the user is rooted, the traffic is intercepted and the binary has been pulled apart — because for the attackers who matter, all three are true.

Binary / secrets Local storage Keystore TLS / pinning Backend API Client checks bypassed
MASVSOWASP standard
iOSand Android
Binary+ backend testing
RootedDevice analysis

The client-side trust problem

Mobile applications are built by teams who are used to controlling the runtime. On a server you decide what executes. On a phone you ship a binary to a stranger and hope. Anything you put in that binary — an API key, a signing secret, an encryption key, a feature flag that unlocks premium functionality — is available to anybody who cares to look, and pulling apart an APK is a fifteen-minute job for someone with the right tools.

The pattern we see repeatedly is validation performed in the app and trusted by the server. The application checks that the amount is positive, that the coupon is valid, that the user has a subscription — and the API accepts whatever arrives. Remove the app from the equation, speak to the API directly, and every one of those checks disappears.

So a mobile assessment is really two assessments. One looks at the application on the device: what it stores, what it logs, how it protects its own traffic, and what falls out of the binary when it is decompiled. The other looks at the backend the way a modified client would — which is where most of the severe findings end up.

Coverage

What we test

Coverage follows the OWASP Mobile Application Security Verification Standard and the associated testing guide.

Local data storage

Databases, preferences, caches, logs and temporary files examined on a rooted or jailbroken device — including the personal data written to logs during error handling.

Cryptography on device

Key generation and storage, use of Keychain and Keystore, hardcoded keys, and homegrown encryption where a platform primitive should have been used.

Network communication

Transport configuration, certificate validation, certificate pinning and whether that pinning survives a determined attempt to remove it.

Authentication and session handling

Token storage and lifetime, biometric implementation, background and lock behaviour, and whether a session survives a device compromise.

Platform interaction

Exported components, deep links, custom URL schemes, clipboard behaviour, screenshot and backup exposure, and inter-process communication.

Code quality and resilience

Obfuscation, anti-tampering, root and jailbreak detection, and debug functionality left in a release build.

Reverse engineering

Static analysis of the decompiled application for secrets, endpoints, hidden functionality and business logic that should never have been client-side.

Backend APIs

The services the application talks to, tested as an API in their own right — usually where the highest-severity findings are.

Approach

How a mobile test runs

Typically six to ten working days per platform, depending on the size of the application and whether the backend is in scope.

  1. 01 · Intake

    Builds for each platform, test accounts at every privilege level, and a walkthrough of what the application is for.

  2. 02 · Static analysis

    The binary is decompiled and examined for secrets, endpoints, debug artefacts and hardcoded logic, alongside automated analysis across the relevant language packs.

  3. 03 · Dynamic analysis

    The application is run on instrumented rooted and jailbroken devices, with storage, logging, memory and inter-process behaviour observed under real use.

  4. 04 · Traffic analysis

    All network communication is inspected, including whatever protections exist against inspection.

  5. 05 · Backend testing

    The API is tested independently of the app, with client-side controls deliberately bypassed.

  6. 06 · Report and retest

    Findings split by platform and by layer, with a free retest once fixes are released.

Run against recognised standards

  • OWASP MASVSMobile verification standard
  • OWASP MASTGMobile testing guide coverage
  • OWASP API Security Top 10Backend API coverage
  • CWEWeakness classification

Deliverables

What you actually receive.

The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.

Per-platform findings

Android and iOS reported separately, because the fixes usually are.

Extracted evidence

The secrets, endpoints and logic we recovered from the binary, shown as recovered.

MASVS coverage statement

Which verification requirements were met at the level you are targeting.

Backend findings

API issues reported as API issues, with the client-side control that was supposed to prevent them noted.

Free retest

Verification against the fixed build once it is available.

Is this for you?

Talk to us if any of these are true.

If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.

Book a scoping call
  • Your app handles payments, health data, KYC documents or location history.
  • You are publishing to the Play Store or App Store for the first time.
  • An enterprise customer has asked for a mobile penetration test report.
  • Your app and web product share a backend that has only ever been tested through the browser.
  • You have implemented certificate pinning and want to know whether it holds.

How we work

Six steps, and no surprises.

The same engagement model applies to every piece of work we take on, so you always know what happens next.

01

Scope

A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.

02

Authorise

Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.

03

Test

Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.

04

Report

One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.

05

Remediate

A walkthrough call with your engineers. We answer questions on the fix, not just the finding.

06

Retest

A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.

Questions

Mobile Application Testing — answered.

The questions clients actually ask during scoping. If yours is not here, ask it directly.

Do you need the source code?

No. We test the compiled application the way an attacker would, which means decompiling the binary you actually ship. Source access is welcome and makes the review deeper — we can combine it with a secure code review — but it is not required, and testing without it is a more honest simulation of the real threat.

Do you test on real devices or emulators?

Both. Emulators are efficient for repeatable analysis, but some behaviour only appears on physical hardware — biometric flows, hardware-backed key storage, and certain platform protections. We use rooted and jailbroken physical devices for the parts that require them.

Is the backend included?

It should be, and we recommend scoping it in. The majority of high and critical findings in mobile engagements are in the API rather than the app, because that is where the real authorisation decisions are made. If the backend is genuinely out of scope we will say so clearly in the report so nobody mistakes a limited test for a complete one.

We have obfuscation and root detection. Is testing still worth it?

Yes. Obfuscation raises the effort required, it does not prevent analysis, and root detection is routinely bypassed. Both are worth having — they filter out casual attackers — but they are speed bumps, not controls. The test tells you what an attacker finds after they get past them, which is the question that actually matters.

How long does a mobile assessment take?

Six to ten working days per platform for a typical application, plus reporting. Testing both Android and iOS together is more efficient than two separate engagements, since the backend work is shared.

Next step

Get a written scope and a fixed price.

A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.