Local data storage
What the app writes to disk and whether it should: shared preferences and plists, SQLite and Realm databases, caches and logs, WebView storage, and what survives an unencrypted device backup.
Services · iOS & Android
Mobile application
Mobile application
penetration testing.
A mobile app ships your client code to every attacker who downloads it. They can read it, instrument it at runtime, and talk to your API without it. We test the app the way someone who has already unpacked it would, and we spend most of our time on the API behind it, because that is where the findings that matter usually are.
01
Who this is for
Built for teams whose product lives in an app store.
01
Fintech and regulated products
Where the app handles payments, identity or health data, the questions are specific: what is written to disk, what survives a backup, what a jailbroken device can reach, and what the API accepts once pinning is removed.
02
Startups approaching a review or a raise
App store review, enterprise procurement and investor diligence all ask whether a qualified third party has tested the mobile client. This produces that evidence, with remediation your developers can act on rather than a rating.
03
Teams on a release cadence
Findings arrive mapped to the code and the endpoint that produced them, as SARIF and JSON, so they enter your backlog as tickets rather than as a document someone has to translate first.
02
Coverage
What we actually test.
Static analysis of the package, dynamic analysis on a real instrumented device, and a full pass over the API the app depends on.
Keychain, Keystore and cryptography
Key generation, storage and protection classes, hardware backing where it is claimed, custom or rolled cryptography, hardcoded keys and secrets recoverable from the package.
Transport and pinning
TLS configuration, certificate and public-key pinning, whether pinning can be removed at runtime, and critically what your API accepts once it has been. Pinning is a speed bump, not a boundary.
Platform surface
Exported activities, services, providers and receivers on Android, URL schemes and universal links on iOS, deep link handling, IPC, clipboard exposure, and screen and snapshot leakage.
Runtime and device integrity
Root and jailbreak detection and how quickly it falls, anti-debugging and anti-instrumentation, code obfuscation in practice rather than in principle, and what an attacker gains after each is bypassed.
The backend API
Authentication and token lifecycle, authorisation on every endpoint the app calls, IDOR and BOLA against user-owned objects, mass assignment, and endpoints the app no longer calls but the server still serves.
03
How the engagement runs
Six steps, every time.
The same disciplined sequence on every engagement, so you know what is happening and when, and so nothing reaches your report unproven.
01
Scope
A conversation, not a form. We agree the boundary, the accounts, the timing and the escalation contact, and it is enforced technically.
02
Map
We build the real picture of what is reachable, which is almost always larger than the inventory you were given.
03
Prove
Every candidate finding is actively validated against a baseline. Anything that fails is demoted or dropped before it reaches you.
04
Chain
Confirmed findings are linked into the routes an attacker would walk. One finding is a ticket. A path is a breach.
05
Report
Evidence, reproduction steps, prioritised remediation and detection content, as SARIF, JSON and HTML mapped to MITRE ATT&CK.
06
Retest
You fix, we verify, and the report is updated. A finding is not closed because someone said it was.
04
Straight answers
The questions we actually get.
Do you need our source code?
No. We can work black-box from the published package, and often should, because that is the attacker's position. Source access makes the review deeper and faster, so if you can share it we will use it, but it is not a prerequisite.
Do you test both iOS and Android?
Yes, and they are scoped as separate work because they genuinely differ. The same feature can be safe on one platform and exposed on the other, most often in storage and IPC. If budget forces a choice we will tell you which platform carries more risk in your case.
Our app has certificate pinning. Does that cover us?
Pinning raises the cost of interception on a normal device. It does not stop anyone with an instrumented one, and it is routinely bypassed in minutes. The real question is what your API does once pinning is gone, and that is what we spend the time on.
Does testing require access to production?
Usually no. A staging build against a staging backend is normally sufficient, as long as the authorisation logic and data model match production. Where they diverge we will say so rather than report findings that will not transfer.
How long does it take?
A single platform with a moderate feature set and its API is typically one to two weeks including reporting. Two platforms, or an app with heavy offline functionality, takes longer. You get the scope and the number before committing.
Start here
Scoping is
Scoping is
a conversation.
Tell us what you are protecting and what worries you. You will get an honest answer on whether this engagement is the right next step, who would run it, and what it would cost, before you commit to anything.