Mobile app testing on the device an attacker holds.
Your app ships to a phone you don't control. We test the binary, the data it keeps, and the APIs behind it, on real rooted and jailbroken devices.
- Shipping to the app stores:
- catch the issues that trigger a review rejection before you submit.
- A customer asked for a report:
- findings mapped to MASVS, a recognised benchmark.
- Tested on physical rooted and jailbroken devices
- iOS and Android in one report
- Findings mapped to OWASP MASVS
- Backend APIs tested too, retest included
What is a mobile application penetration test?
A mobile app gives an attacker the binary, the local storage and unlimited time. A penetration test attacks all of it: the app, the device it runs on, and the APIs behind it, following the OWASP Mobile Application Security Verification Standard (MASVS), an open control set for mobile security.
What we test
- The app binary
- Data stored on the device
- Traffic to the backend
- Sign-in and biometrics
- Deep links and permissions
- The backing APIs
What you get back
- Findings mapped to MASVS
- Device and OS context
- Fixes per platform
- iOS and Android together
- A retest of the fixes
- Store-review readiness
APP
A recognised benchmark for your app
Findings are mapped to MASVS, so your results are comparable against a recognised standard, with the device context to reproduce each one.
The backend APIs are tested too, because mobile risk rarely stops at the client.
Six areas every mobile test covers
Local storage
Keychain and Keystore, databases, caches, logs and backups.
Transport
TLS, certificate validation and pinning, and bypasses.
Authentication
Token storage, biometrics and behaviour on device loss.
Binary and runtime
Reverse engineering, root detection, hooking, tamper resistance.
Platform interaction
Deep links, exported components, clipboard and permissions.
Where mobile testing matters most
- Banking and payments
- Health apps
- Retail apps
- SaaS companions
- Workforce apps
- Education apps
The trigger is usually a first release, a store review rejection, a customer security review, or storing sensitive data on the device.
Browse plain-language security guides in the Resources libraryWhat sits in scope of a mobile app test?
Three layers: the device, the app on it, and the backend it talks to. An attacker who holds the phone can work on all three, so the test does too.
01 · The device
Phone and operating system
- Rooted and jailbroken devices
- Local storage
- Keychain and Keystore
- Backups
An attacker with the device controls the environment the app runs in.
02 · Your app
Binary and runtime
- Decompiled code
- Hardcoded secrets
- Runtime hooks
- Deep links and components
Static and dynamic analysis find what the client-side controls really protect.
03 · Your backend
APIs behind the app
- Authentication endpoints
- Data endpoints
- Third-party services
Tested like a standalone web service, without the app in the way.
If your app keeps tokens or personal data on the device, or unlocks features with a client-side check, the device layer is already part of your risk.
The APIs behind the app are tested directly, outside the app's own limits. Third-party SDKs inside the app are in scope too, where we can inspect them.
How a mobile application test runs
Six steps, each with a named output and a clear ask of your team. Static and dynamic analysis are the core, then the backend.
- Scope
Scoping
We agree platforms, builds, test accounts and whether source code will be provided.
- Platforms
- Builds
- Test accounts
- Source access
- You get
- A written scope and rules of engagement.
- You provide
- Builds for each platform and test accounts.
- Static
Static analysis
We decompile and inspect the binary for hardcoded secrets, weak cryptography and insecure configuration.
- Decompiled code
- Hardcoded secrets
- Cryptography
- Configuration
- You get
- A list of binary-level findings.
- You provide
- A pre-release build with debug symbols, if possible.
- Dynamic
Dynamic analysis
We run the app on rooted and jailbroken devices, intercept its traffic and watch what it does at runtime.
- Traffic interception
- Local storage
- Runtime behaviour
- Pinning checks
- You get
- Runtime findings with device context.
- You provide
- Access to the test environment the app talks to.
- Runtime
Runtime manipulation
We hook the app to test whether client-side controls can be bypassed, and what that exposes.
- Hooking
- Root detection bypass
- Tamper resistance
- Feature unlocks
- You get
- A view of which client-side controls actually hold.
- You provide
- Answers about intended behaviour.
- Backend
Backend testing
We test the supporting APIs directly, outside the app's own constraints, with the same rigour as a web service.
- Authentication
- Authorization
- Rate limits
- Data exposure
- You get
- API findings alongside the app's.
- You provide
- API documentation and test credentials.
- Report
Report & retest
You get reproducible findings with device context, a walkthrough, and a retest of the fixes.
- Findings report
- Walkthrough
- Retest
- Attestation letter
- You get
- A report, a walkthrough and a reissued report after retest.
- You provide
- Engineers on the walkthrough, and the fixes to retest.
There's no one-size timeline: it depends on the number of platforms, screens and APIs in scope, and whether we get source code. You get a firm estimate in writing during scoping.
What you receive
The engagement ends in one test file. Each item is paired with the question a reviewer or a customer's security team asks about it.
Each finding comes with platform-specific fix guidance and a retest that verifies it, so the evidence that it is closed exists before anyone asks.
A mobile penetration test isn't a certificate; it's evidence. Customers and your own team judge it by how reproducible the findings are and whether fixes were verified.
01, Report phase: Executive summary
Written for non-technical stakeholders.
02, Scope phase: Scope and builds tested
Platforms, build numbers and access, as agreed.
03, Static phase: Binary analysis
Secrets, cryptography and configuration findings.
04, Dynamic phase: Runtime findings
Storage and traffic findings with device and OS context.
05, Runtime phase: Client-side control review
Which controls held and which did not.
06, Backend phase: Backend API findings
API issues found by testing directly.
07, Report phase: Findings mapped to MASVS
Every finding against the MASVS control set.
08, Report phase: Retest report
Every fix verified, report reissued.
Illustrative example, not client data
What one finding looks like
- Title
- Session token readable from app storage
- Area
- Local data storage
- Platform
- Android (rooted device)
- Steps
- Open the app's data folder, read the stored token
- Impact
- Anyone with the device can take over the session
- Fix
- Keep the token in the platform's secure storage
Four common mobile testing misconceptions
Each one is common, reasonable, and the reason an app ships with avoidable holes.
Assumption 01
Assumption: The app store review already checks security.
What testing actually shows
Store review looks for policy issues, not a deep security assessment of your app and its data.
Assumption 02
Assumption: An emulator is enough to test an app.
What testing actually shows
Emulators miss platform behaviour. We test on physical rooted and jailbroken hardware.
Assumption 03
Assumption: If iOS is clean, Android is too.
What testing actually shows
The platforms have different storage, permission and runtime models, so a finding on one may not exist on the other.
Assumption 04
Assumption: Testing the app is enough.
What testing actually shows
Mobile risk rarely stops at the client. The APIs behind the app need the same rigour.
Heard one of these from your team? A scoped mobile test shows where you really stand.
Get a mobile app test scopedWhat you can hold us to.
We don't publish client logos next to findings; we keep our clients' security posture private. These are the commitments we make instead.
Our commitments
Senior testers on the work
Every engagement is led by experienced practitioners, not handed to a junior running a scanner.
Peer-reviewed reports
Every report is peer-reviewed before it reaches you.
Written scope and rules
You know what is tested, when, and what happens if scope changes, before work starts.
Retesting included
We verify your fixes and reissue the report, so closure can be shown.
The Mobile Application Security Testing service from Auditify Security was exactly what we needed. They found vulnerabilities we didn't even know existed and helped us fix them before they could be exploited. Highly recommend for any company looking to secure their mobile apps.
Want to speak to a client? Ask for a reference while we scope your work and we'll arrange it directly.
Ask for a referenceMobile testing questions buyers ask
Do you need our source code?
No, but it helps.
We can test a compiled binary alone, and go deeper and faster with source access. Either is valid; we agree which during scoping.
Test the app before an attacker does.
Send the basics
What you want tested (platforms, builds and APIs), who uses it, and any deadline such as a customer review or an audit.
We scope the work
We respond within 24 hours, then agree targets, access and rules of engagement in writing.
Your test, then your retest
You get a reproducible report, a walkthrough with your engineers, and a retest of the fixes.
- Shipping to the app stores:
- catch the issues that trigger a review rejection before you submit.
- A customer asked for a report:
- findings mapped to MASVS, a recognised benchmark.
We test and report. We don't change your app or systems; fixes are made by your team, and we verify them.