Mobile Application Security
Mobile app penetration testing for iOS, Android and backend APIs
Test the release build, device storage and runtime together with the agreed backend API. Receive MASVS-mapped findings, remediation guidance and a retest.
Scope agreed in your proposal: platforms and builds, test accounts, backend API and release deadline.
Case study: an app shipped as a credential vault →
Follow the app beyond the screen.
Connect the binary, the device and the API behind the application.
The client is in the attacker’s hands, not yours
Every other target you own. A mobile app you give away: the bundle ships to anyone with the store listing, and from that moment the binary, the local data store and the runtime are an attacker’s to take apart at leisure. We start where they do — unpack the shipped artefact and read it — because what is compiled into it cannot be revoked by a server-side change. On one engagement that was enough to recover backend credentials granting a live, authenticated session to an internal customer-data API; the full chain is published.
The second half of the work is the part scanners never reach: hooking the running app to see what its defences actually hold up to. Root and jailbreak detection, certificate pinning and anti-tampering are controls we expect to be able to defeat; the question we answer is what each one is protecting and how much is left when it is gone. We test the app and the API it talks to as one system, because a client-side control is only a control if the server does not take the client’s word for it.
What we test
- The shipped binary: secrets, keys, endpoints and logic recovered by reverse engineering
- Data at rest: local databases, keychain and keystore use, caches, backups and logs
- Cryptography and key derivation, including keys derivable from the device itself
- Transport: TLS validation, certificate pinning and the configuration that disables it
- Platform surface: deep links, IPC, exported components, WebViews and embedded local servers
- Resilience: root and jailbreak detection, anti-debugging, anti-tampering and runtime hooking
- Authentication, session handling and biometric gating
- The back-end API the app talks to, tested as part of the same system
Why it matters
The app is the only part of your system you hand to the attacker
Everything else you run sits behind something you control. A mobile app does not: you publish the bundle, and from that point the binary, the data it writes to the device and the behaviour of the running process all belong to whoever downloads it. That changes what counts as a secret. A key compiled into the artefact is not configuration you can rotate quietly — it is in every installed copy, on every device, until users update, and some of them never will.
This is why mobile findings tend to be worse than they first look. A credential in a shipped bundle is not one app’s problem; it is a working session against whatever that credential reaches. A local store encrypted with a key the device itself can produce is not encrypted in any useful sense. And a control that lives only in the client — pinning, root detection, a disabled debug flag — holds for exactly as long as it takes somebody to hook the function that evaluates it.
So we test in the order the attacker works: read the artefact first, instrument the running app second, and then follow whatever the client has exposed into the API behind it. The things that get fixed as a result are usually architectural — move the secret to the server, derive the key properly, stop trusting the client — rather than a list of flags to flip.
How it works
Scope and builds
Platforms, build artefacts, test accounts and device or emulator access agreed up front.
Static analysis
We unpack and reverse the shipped bundle: the secrets, endpoints, key material and logic it gives away.
Dynamic and runtime
Instrumented testing on device — hooking, interception, storage inspection and control bypass — followed through into the API behind the app.
Report and retest
Findings mapped to the MASVS control groups, prioritised, then verified and confirmed in writing.
Why PXLSec
What sets our mobile testing apart
Reverse engineering, not just a scan
We unpack and read the shipped bundle by hand. Mobile scanners report the presence of patterns; recovering a usable credential, an at-rest key or the real endpoint list from a stripped or obfuscated binary is manual work, and it is where the serious findings come from.
Runtime instrumentation as standard
We hook the running app rather than reasoning about it from the outside. Pinning bypass, root and jailbreak detection bypass, storage inspection and method tracing are part of every engagement, so every finding comes with proof from the live process.
Cross-platform apps tested as cross-platform
A React Native, Flutter or MAUI app is one codebase with different failure modes on each target. We test each platform build, because the same bug is not always the same severity — and some only exist on one of them.
The API is in scope, not next door
Mobile findings almost always end at a server. We test the back end the app talks to as part of the same engagement, so a weak client control is followed through to whether the server actually depends on it.
What you receive
Clear deliverables, agreed in the proposal, with no surprises at the end of the engagement.
- Executive summaryBusiness-level risk, written for leadership and boards.
- MASVS-mapped reportEvery finding with its severity, evidence, reproduction steps and the MASVS control group it sits in — plus the recovered artefacts and intercepted traffic behind it.
- Prioritised fixesDeveloper-ready remediation for the platform and framework you actually build on.
- Retest letterWe verify your fixes and confirm closure in writing.
When you need this
When a mobile test pays off
These are the moments when testing the app itself answers a question that testing your APIs cannot.
Before a release reaches the stores
Once a build is published you cannot take it back, and a secret inside it stays live on every installed copy. Testing the release candidate is the last point at which that is cheap to fix.
The app holds data on the device
Offline modes, cached records, local databases and “remember me” all mean customer data at rest on hardware you do not control. We test whether the encryption around it survives contact with the device.
An enterprise app shipped to customers
If your app is deployed into other organisations' device fleets, their MDM configuration becomes part of your threat model. We have found a management default silently disabling certificate pinning — a control the vendor believed was on.
A customer, auditor or store review is asking
Enterprise buyers and regulated sectors increasingly ask for independent mobile testing against a recognised standard. A MASVS-mapped report answers that directly, and the retest letter documents closure.
Methodology & standards
Methodologies and references we draw on
- OWASP MASVS (Mobile Application Security Verification Standard)
- OWASP MASTG (Mobile Application Security Testing Guide)
- OWASP Mobile Top 10
- OWASP API Security Top 10
- NIST SP 800-163 (vetting mobile applications)
- CWE
- CVSS and EPSS for severity context
FAQ
Questions we're often asked
How is this different from your penetration testing service?
Our penetration testing service covers a mobile app as one target among several, and for many scopes that is the right engagement. This one is the deeper version: the whole budget goes on the app, the testing is structured around the MASVS control groups, and the report is mapped to them. If you are testing a web platform that happens to have an app, start with penetration testing. If the app is the product, or somebody is asking you for mobile-specific assurance, start here.
Which platforms and frameworks do you test?
Native iOS and Android, and cross-platform apps built with React Native, Flutter, .NET MAUI, Xamarin, Cordova and similar hybrid stacks. We have run engagements covering iOS, Android and Windows builds of the same product in one piece of work. If you are on something unusual, tell us at scoping and we will say plainly whether we are the right firm for it.
Do you need our source code?
No. We work from the shipped artefact by default, because that is what an attacker has, and testing it that way is the only honest measure of what the binary gives away. If you can provide source as well we will use it to go further and faster, but it is not a prerequisite.
What do you need from us to start?
The build artefacts for each platform in scope — an IPA or a TestFlight invite, an APK or AAB — plus test accounts with the roles that matter, and any back-end environment you would rather we point at than production. Physical devices are not usually something you need to supply.
Will you bypass our root detection and pinning?
Almost certainly, and that is not the finding. Client-side resilience controls raise the cost of attack; they do not stop it, and any report that treats a bypass as a critical result on its own is padding. What we report is what each control was protecting and what is actually exposed once it is gone — and, where the controls are genuinely weak for the risk the app carries, we say so and how to strengthen them.
Is a retest included?
Yes, as standard. Once your team has addressed the findings we retest each one and issue written confirmation of what is closed, which you can show to customers and auditors.
Related services
Discuss your testing scope.
Tell us what you want to protect. A senior tester will help you agree the scope and next steps. We usually reply within one business day.
Confidential from the first conversation
We can sign your NDA before you share sensitive details. Your enquiry is covered by our privacy policy.
How we protect your information · Privacy policy