Insecure data storage
Access tokens, personal data, or documents end up unencrypted in SharedPreferences, NSUserDefaults, SQLite databases, caches, or log files. On a compromised device or via a backup, they are easy to extract.
Penetration Testing
Mobile App Penetration Testing for iOS and Android
iOS & Android – app, device, and API covered
Your app runs on devices you don’t control and talks to interfaces whose traffic can be intercepted and manipulated. With mobile app penetration testing, we examine iOS and Android apps – including their backend – based on OWASP MASVS and MASTG, and show you where data, accounts, and business logic are vulnerable.
- Fixed price after scoping
- Free retest
- Quote within 24 hours
Definition
What is mobile app penetration testing?
Mobile app penetration testing – also called a mobile app pentest or, for short, an app pentest – is a predominantly manual security assessment of your iOS and Android application from an attacker’s perspective. We examine the app itself, its runtime behavior, the data it leaves on the device, and the interfaces it communicates with. The goal is to find and prove exploitable vulnerabilities before criminals discover them.
Mobile apps are fundamentally different from web applications. Anyone can download an app from the App Store or Google Play, take it apart, and manipulate it at will on a rooted or jailbroken device. Everything inside the client – API keys, hidden features, root and jailbreak detection, certificate pinning – can be extracted, analyzed, or defeated with enough time and expertise. What matters, therefore, is whether your backend stays secure even when the app no longer “plays along.”
We work according to the OWASP Mobile Application Security Verification Standard (MASVS) and its companion testing guide, the MASTG. The eight MASVS control groups form the framework of our assessment: data storage (MASVS-STORAGE), cryptography (MASVS-CRYPTO), authentication (MASVS-AUTH), network communication (MASVS-NETWORK), platform interaction (MASVS-PLATFORM), code quality (MASVS-CODE), resilience against tampering (MASVS-RESILIENCE), and privacy (MASVS-PRIVACY). We also map findings to the risks of the OWASP Mobile Top 10.
An app pentest is especially important if your app processes personal, financial, or health data, initiates payments, controls devices, or gives employees access to internal systems. The results help you demonstrably meet requirements under Art. 25 and Art. 32 GDPR, ISO/IEC 27001:2022 (Annex A 8.29), or – for financial entities – DORA. Manufacturers of health apps also follow BSI TR-03161, a technical guideline of the BSI (Germany’s Federal Office for Information Security); a pentest conducted beforehand uncovers gaps before they surface in a formal assessment.
The best time to test is before the first store release and after every major change – to the login, payment function, embedded SDKs, or API, for example. That way, the results feed directly into the next build, and you avoid costly fixes after launch.
Our approach
How we test your iOS and Android app
We combine static and dynamic analysis. First, we unpack the app package (IPA, APK, or AAB), decompile or disassemble the code, analyze the AndroidManifest, Info.plist, and entitlements, and look for hard-coded secrets, libraries in use, debug functions, and hidden endpoints.
Next, the app runs on prepared test devices – rooted or jailbroken and, if needed, in their factory state. Using instrumentation frameworks such as Frida, we observe and modify its runtime behavior, bypass certificate pinning as well as root and jailbreak detection, and route all traffic through an intercepting proxy. After each step, we check what traces the app has left on the device.
We focus where the greatest damage can occur: the backend APIs. Using test accounts with different roles, we check whether other users’ data can be retrieved, prices changed, or approvals bypassed – regardless of what the app’s interface allows. Our certified pentesters and security researchers document every step transparently.
Common vulnerabilities
Common vulnerabilities in mobile apps
Hard-coded secrets
API keys, cloud credentials, or private keys in the app package are quickly found after decompilation. They often grant direct access to cloud storage, databases, or paid third-party services.
Missing authorization in the backend
The API trusts the app and doesn’t check whether a record actually belongs to the logged-in account. Simply changing an ID in the request then returns other customers’ data (broken object level authorization).
Weak authentication and session management
Tokens without an expiration time, refresh tokens that remain valid after logout, or a biometric login that merely checks for a local “yes.” If biometrics aren’t cryptographically bound to the Keychain or Keystore, a single runtime hook is enough to bypass them.
Insecure communication
Flawed certificate validation, cleartext traffic permitted through exceptions in App Transport Security or the Network Security Configuration, or missing pinning in apps with high protection requirements. On public Wi-Fi, traffic can then be intercepted and manipulated.
Insecure platform interfaces
Exported Android components such as activities or content providers, deep links or URL schemes that trigger actions without validation, and WebViews with JavaScript bridges into native code. Other apps on the same device can abuse these paths.
Risky third-party SDKs
Outdated libraries with known vulnerabilities, or analytics and advertising SDKs that transmit more data than documented. That’s both a security and a privacy problem.
Insufficient protection against reverse engineering
For banking, payment, or licensing apps, missing obfuscation, easily bypassed root detection, or missing integrity checks become a risk – for example, when tampered copies of the app start circulating.
Testing perspective
Black, gray, or white box – which test fits your app?
How much information we receive in advance determines the depth and efficiency of the test. We’ll advise you on which option fits your goal.
No prior knowledge
Black box
We start with nothing but the publicly available app – like an attacker who downloads it from the store.
- Realistic outside view
- Focus on reverse engineering and runtime analysis
- Protected areas often remain out of reach without test accounts
Recommended
Gray box
You provide test builds, test accounts for all roles, and API documentation – the most efficient approach for most apps.
- Coverage of all features and roles
- Targeted authorization tests in the backend
- Good balance of effort and results
With source code
White box
We also review the source code and architecture, which lets us find vulnerabilities that are barely visible at runtime.
- Combination of pentest and code review
- Cryptography and key management in detail
- Ideal for high protection requirements
Process
Your app pentest in six steps
We align the test with your release cycle so the results make it into the next build in time. Methodologically, it follows our proven approach to penetration testing.
-
01
Scoping & threat model
We clarify platforms, app versions, roles, test environment, and protection requirements, and decide whether resilience against reverse engineering will also be tested. You receive a fixed-price quote within 24 hours of scoping (on business days).
-
02
Static analysis
We unpack the IPA and APK, analyze the manifest, Info.plist, permissions, and libraries, and look for secrets, weak cryptography, and hidden endpoints.
-
03
Dynamic analysis
On prepared test devices, we observe and manipulate the app at runtime and examine data storage, inter-process communication, biometrics, and protection mechanisms.
-
04
API and backend testing
We intercept the traffic and test authorization across multiple roles, input validation, and business logic – including endpoints the app itself never calls.
-
05
Report & debrief
You receive an executive summary, technical findings with CVSS ratings, and concrete measures for iOS, Android, and the backend. On request, we walk through the results with your team.
-
06
Retest & test certificate
Once the corrected build is ready, we retest the remediated vulnerabilities free of charge. After the test is complete, you also receive a test certificate.
Reporting
A report for development and management
Every finding is documented so your development team can reproduce and fix it – with the affected platform and version, reproduction steps, evidence, and a concrete recommendation. The executive summary condenses risks and priorities so decisions can be made without reading every single request.
- Executive summary with an overall rating
- Findings with CVSS ratings and mapping to the OWASP MASVS
- Reproduction steps, screenshots, and requests as evidence
- Remediation recommendations broken down by iOS, Android, and backend
- Debrief on request
- Free retest and test certificate
Is your next release coming up?
Schedule the pentest before the store release. We coordinate the testing window and build with your development team so vulnerabilities are fixed before your users install the app.
FAQ
Frequently asked questions about mobile app penetration testing
Didn’t find your question? Call us at +49 2932 465265-0 or email info@rootsektor.de.
Do you test iOS and Android apps?
Yes, we test both platforms – individually or together. Because iOS and Android come with different security mechanisms, such as the Keychain and Keystore or App Transport Security and the Network Security Configuration, we test platform-specific aspects separately. We test the shared backend API only once, which saves effort.
Is the backend API part of the test?
Yes, because that’s often where the most consequential vulnerabilities lie. We also call your app’s endpoints with manipulated parameters, other users’ object IDs, and the privileges of other roles. If web applications or partners use the same interface, a dedicated API penetration test is worthwhile.
What do you need from us for the test?
Ideally, test builds for both platforms – an ad hoc or development build as an IPA for iOS and an APK or AAB for Android – plus test accounts for each role and access to a test or staging environment. API documentation, for example in OpenAPI format, speeds up the test. For a white-box test, we also need source code and architecture documents.
Do you follow OWASP MASVS and MASTG?
Yes. The MASVS defines which security requirements an app should meet; the MASTG describes how to test them. Depending on your protection requirements, we align the depth of testing with the MAS profiles L1 (baseline security), L2 (elevated protection requirements), and R (resilience against reverse engineering and tampering).
Do you also test cross-platform apps such as Flutter or React Native?
Yes. Cross-platform frameworks have their own peculiarities: Flutter apps, for example, ignore the system’s proxy settings and ship their own TLS stack, while React Native apps contain their logic as a JavaScript bundle or Hermes bytecode. We take this into account in our analysis and choice of tools – as we do for .NET MAUI, Ionic, or Capacitor.
Do we have to disable root or jailbreak detection for the test?
It’s not mandatory, but it often makes sense. We’re happy to test both: whether the protection mechanisms themselves can be bypassed and – in a build without this protective layer – the actual app logic. That way, testing time goes into the vulnerabilities that really matter.
When should an app be tested?
Ideally, once the feature set for the release is final but there’s still time for fixes – that is, before submission to Apple or Google. Another test is worthwhile when security-relevant features are added, such as single sign-on, a wallet integration, or device functions like NFC. For apps that handle sensitive data, we also recommend regular testing, e.g., annually.
How long does an app pentest take, and how much does it cost?
Duration and effort depend on the feature set, the number of roles and platforms, and the depth of testing you need. After scoping, you receive a fixed-price quote within 24 hours (on business days) – with no hidden costs and a free retest.
Related pages
Have your app tested
Briefly describe your app, the platforms, and your planned release date. We’ll get back to you to arrange a no-obligation initial consultation and send you a fixed-price quote within 24 hours of scoping (on business days).