Static analysis
Hardcoded keys, debuggable builds, exported components, insecure IPC, leftover admin flags.
MobSFSecretsIPC
Coverage
Store listing vs what the binary actually does
Transport & pinning
User-trusting TLS, pinning that is not pinning, interceptable tokens on public Wi-Fi.
MITMPinningTLS
Local storage
Plaintext tokens in prefs, backups, logs, screenshots, clipboard, and keyboard cache.
KeychainShared prefs
Backend abuse
The app is a client. The money is in the API. Two-account tests against the same endpoints the app calls.
APIBOLA
UK financial and health apps get asked for independent mobile testing in vendor packs. We do not claim sector accreditation we do not hold. We do produce the technical evidence those questionnaires are reaching for.
Why it matters
The app is the front door. The API is the building.
Most mobile findings are not in the app
A mobile client is a wrapper around an API, and that is where the serious findings live: object-level authorisation, endpoints that trust a user ID from the request, admin functions reachable with a customer token. We test the binary properly, but any mobile engagement that ignores the backend is theatre. The API is in scope by default.
Certificate pinning is not the security boundary
Pinning slows an attacker down by an afternoon. We bypass it — Frida, patched binaries, a rooted or jailbroken device — precisely because a motivated attacker will, and then we test what pinning was protecting. If pinning is the only thing standing between a customer and your API, you need to know now.
What the device keeps after logout
Access tokens in shared preferences, PII cached in SQLite, session data in plist files, secrets compiled into the binary, screenshots retained in the task switcher, data written to external storage. On a lost or shared handset this is the whole breach. It is also the finding an ICO enquiry will ask about first.
Two platforms, two answers
Android and iOS fail differently: exported components, deep links and WebView configuration on one side; keychain accessibility, URL scheme handling and IPC on the other. We test both against the platform’s own security model rather than running one checklist across both and hoping.
A mobile engagement covers three surfaces: the compiled client, the data it leaves on the device, and the API it talks to. Price and timeline assume all three, because testing one in isolation produces a report that reassures nobody.
How it runs
The engagement, step by step
Scope and authorisation
Which builds, which platforms, which backend environment, which accounts. Written CMA 1990 authorisation covering the API as well as the app, signed before anything starts.
Builds and devices
You supply a debuggable build or the store binary plus test credentials. We work on rooted Android and jailbroken iOS devices as well as stock hardware, so we can see both the attacker’s view and the ordinary user’s.
Static analysis
Decompilation, manifest and entitlement review, hardcoded secrets, third-party SDKs, exported components, deep-link handlers, WebView settings, and what the build actually ships that the developers think it does not.
Runtime and storage
Pinning bypass, traffic interception, hooking, local storage and keychain review, logging, backup behaviour, screenshot and clipboard handling, and what survives a logout or an app switch.
API testing
The full backend behind the app: authorisation per object, token handling and expiry, replay, mass assignment, rate limiting, and whether a customer token reaches anything it should not.
Report and re-test
Findings split by platform and by backend, each with reproduction steps against a named build. Re-test of every confirmed issue after you ship the fix, included.
Deliverables
What lands on your desk
Findings by surface
Separated into client, on-device data and API, so the right team picks up the right work. Each finding names the build and platform version it was proven against.
Reproduction that survives a release
Steps written against behaviour rather than screen coordinates, with the tooling and device state needed, so your developers can reproduce a finding three sprints later without us.
OWASP MASVS alignment
Mapped to the OWASP Mobile Application Security Verification Standard, plus ISO 27001 and UK GDPR relevance where the finding involves personal data on the device.
Re-test and attestation
Re-test of confirmed findings on the fixed build, in the original fee, and a letter of attestation naming scope, platforms, dates and outcome for your app-store or enterprise customer paperwork.
Scoping
What we need from you to start
- An installable build for each platform in scope — an APK or AAB, and an IPA or TestFlight access.
- Two accounts per role on the backend environment we are allowed to test against.
- The API base URL for that environment, and confirmation it is in scope in writing.
- Any device or OS versions you specifically support, especially if you still support older Android releases.
- Whether the app uses a third-party MDM, SDK or payment component you do not control, so we can scope around it.
- A named contact who can push a new build if we need one mid-engagement.
We do not need your source code. If you are willing to share it, findings get more precise and the fix advice gets more specific — but the test is designed to run entirely black-box against the shipped binary.
UK compliance
Where this sits in a UK compliance programme
UK GDPR, Article 32
Personal data cached on a handset is processing, and a lost phone is a plausible breach scenario. On-device storage findings are the ones an ICO enquiry tends to focus on, and they are the easiest to fix before anyone asks.
ISO/IEC 27001
Evidences secure development and technical vulnerability management for the mobile estate, which internal auditors frequently find is out of scope of everything else the organisation does.
Enterprise due diligence
Large customers increasingly send a mobile-specific questionnaire. A MASVS-aligned report with a re-test answers most of it directly and stops the eight-week email thread.
App store and platform review
Store review checks policy compliance, not security. Findings such as exported components, permissive WebViews or shipped secrets pass review comfortably and are still exploitable.
Questions
What UK buyers ask before signing
No. The engagement is designed to run black-box against the shipped binary, which is what an attacker has. If you share source, findings become more precise and remediation advice more specific, but it is optional.
Yes, and it is included by default. Most serious mobile findings are backend authorisation failures reachable with a valid customer token. A mobile test that stops at the binary would miss them, so we do not sell one.
Four to seven working days for one platform including the API, longer where Android and iOS are both in scope or the backend is large. Reporting adds two to three days. We agree the window before signing.
Yes. Pinning raises the effort for an attacker but does not stop one, so we bypass it and test what it was protecting. Finding that pinning is the only real control is itself a result worth having.
Yes. We can work from the store binary against a test backend, or against production under agreed constraints. Either way we need written authorisation covering both the app and the API before starting.
Related
Engagements that usually run alongside
01
02
03
API security testing
REST and GraphQL: object-level authorisation, mass assignment, rate limits, schema exposure.
02
Web application VAPT
Authorisation, session, injection and business logic in the applications your UK customers log into.
03
Security audit & reporting
The write-up an auditor accepts and a developer can act on, with a re-test to close it out.
Ready to scope a UK engagement?
A thirty-minute call. Assets, timeline, a quote in pounds sterling.
Request a quote