Overview
Consumer apps in the US often sit where several obligations meet: card payments, health information and financial data covered by federal rules. We test the installed app on both platforms and the APIs behind it in one engagement, so a weak token check is not missed because it lived on the server. Findings map to OWASP MASVS for engineers and read plainly for product owners.
A mobile application ships to devices that may be jailbroken, rooted, stolen or running a hostile proxy, so the assumptions a web app can make no longer hold. We test what the app stores on the device, how it protects that data at rest, and whether an attacker with physical or network access can recover credentials, tokens or personal data from files, databases, logs or the keychain and keystore.
We examine the app in motion as well as at rest. That means inspecting transport security and certificate validation, attempting to intercept and modify traffic, and checking platform-specific weaknesses: exported components and deep links on Android, inter-process URL handling on iOS, and insecure use of WebViews on both. Where client-side controls such as root detection or certificate pinning exist, we assess how much real protection they add.
Because most of a mobile app's value lives in its backend, the APIs it calls are in scope by default. A hardened client is of little use if its server trusts any request, so we carry the authorization and logic testing through to the service behind the app. Findings are aligned to the MASVS, scored with CVSS v4.0, and written so your mobile and backend teams each know what to change.
How US engagements run
- Delivered remotely from India, 9.5 hours ahead of US Eastern in US daylight time and 10.5 hours in winter; calls and testing windows are set around your time zone at scoping
- Fixed-price proposals in US dollars, with scope, dates and the free retest written in before any work begins
- Written authorization signed by someone with authority over every target, because the federal Computer Fraud and Abuse Act and state laws make permission the dividing line
- Reports that name the requirement a test supports, such as PCI DSS 11.4, the FTC Safeguards Rule or SOC 2, without claiming a QSA, ASV or C3PAO role we don't hold
What's included
Our approach
- Build intakeWe take your IPA or APK and the test accounts needed for each role and platform.
- Static reviewWe unpack and inspect the build for secrets, configuration and insecure components.
- Dynamic testingOn real devices we exercise storage, transport, platform and runtime behavior.
- Backend testingThe APIs the app calls are tested for authorization and logic flaws.
- Report & debriefFindings are evidenced, scored and explained to your mobile and server teams.
What you receive
- Per-platform findings aligned to the OWASP MASVS
- Static and dynamic evidence for each issue
- CVSS v4.0 scores and prioritized remediation
- Backend API findings where in scope
- Free retest of fixed issues and an attestation letter
Standards & frameworks
- OWASP MASVS
- OWASP MASTG
- OWASP API Security Top 10
- PTES
- NIST SP 800-115
- CVSS v4.0
- SOC 2
Frequently asked questions
Do you need the source code?
No. We can test a compiled IPA or APK as a gray-box engagement using test accounts. Source or build access speeds up static review and improves coverage, so we welcome it where you can share it, but it is not a requirement.
Do you test on real devices or emulators?
Both. Emulators are useful for repeatable static and dynamic checks, but some platform and hardware behavior only appears on physical handsets, so we confirm key findings on real rooted and jailbroken devices across the versions you support.
Is the backend included or priced separately?
The APIs the app relies on are part of a meaningful mobile test, so we include authorization and logic testing of them by default. A very large backend with many unrelated services may be scoped as its own API engagement, which we confirm before we start.
Will a SOC 2 auditor accept your application pentest report?
Penetration testing isn't written into the SOC 2 criteria, yet it is common for auditors and enterprise buyers to look for a recent test. Our report records scope, dates, method and rated findings, and the retest letter shows what was fixed. Your auditor still decides which evidence they accept.
Can testing fit around our US release schedule?
Yes. Testing windows, call times and code-freeze periods are agreed around your time zone at scoping. We deliver from India, which is 9.5 hours ahead of US Eastern during US daylight time and 10.5 hours in winter, and any critical issue is passed to your nominated contact the day it is verified.