Testing scope

Penetration testing of
mobile applications

A mobile app is two separate problems: the code that lands on the user device and stops being your secret, and the backend that trusts that app. We take the APK and IPA apart, inspect traffic despite pinning and check what remains in the phone memory after logout.

  • Android and iOS, including Flutter and React Native
  • Static analysis, dynamic analysis and backend testing in one scope
  • Verification against OWASP MASVS and MASTG

Mobile applications

Duration
usually 7-15 working days
We work to
  • OWASP Mobile Application Security Verification Standard (MASVS)
  • OWASP Mobile Application Security Testing Guide (MASTG)
  • OWASP Mobile Top 10
  • PTES

What exactly we check

We tailor the scope to your environment, but these areas are always covered.

1

Static analysis and reverse engineering

Decompilation of the package, review of code and resources. We look for hardcoded API keys, service credentials, test environment addresses and logic that belongs on the server side.

2

Data on the device

Keychain and Keystore, SharedPreferences, SQLite databases, temporary files, WebView cache, system logs, backups and screenshots in the app switcher.

3

Backend communication

TLS correctness and certificate validation, presence and quality of certificate pinning, attempts to bypass it, sensitive data in URL parameters, unencrypted side channels.

4

Authentication and authorization

Token lifecycle, session refresh, logout on all devices, biometrics and ways around them, PIN codes, account takeover through deep links or custom URL schemes.

5

Environmental resilience

Behaviour on rooted and jailbroken devices, debugger and emulator detection, resistance to runtime code injection (Frida, objection), package integrity after repackaging.

6

Mobile API

We test the backend with the full web application scope: access control, IDOR, business logic and limits. Mobile endpoints are often older and less closely watched than the ones the website uses.

What we find most often

Examples from our projects in this area. Client names and technical details stay in the reports.

  • A payment service API key hardcoded in the application
  • Session token stored in clear text in SharedPreferences
  • Certificate pinning bypassed within minutes, with no additional server-side control
  • A deep link triggering an account action without user confirmation
  • Personal data in system logs readable by other applications
  • Permission checks performed only in the app, never on the backend
  • Tokens not revoked after logout and after a password change
  • Active debug configuration left in the production release

Selected tools

MobSFFridaobjectionjadx and apktoolBurp Suite Professional

Tools take care of the repetitive work. The conclusions and attack chains are built by hand.

How the test runs and what you get

The testing process, the report format and the retest rules are the same across every scope.

See the full process and report contents

Frequently asked questions

Do you need the source code?

No, we normally work black box on the finished APK and IPA. Access to the code shortens the work and helps confirm the root cause, so if you can share it the test will be more thorough.

How do we hand over the iOS build?

TestFlight is easiest, or an IPA with an ad hoc profile that covers our devices. We need a build without a forced update so it stays usable for the whole testing period.

Do you test Flutter and React Native apps?

Yes. What differs is mainly the static analysis layer and the way we intercept network traffic. The scope, the standards and the report format stay the same.

Does the backend have to be ordered separately?

No, the API the app uses is part of this scope. We quote separately only when the same backend also serves a large web application that you want covered in full.