Cenvox Global Solutions
Smartphone with security and privacy icons, representing mobile application security testing

Offensive & Application Security

Mobile application security testing for Android and iOS

Security testing of Android and iOS apps and the APIs behind them: data storage, network traffic, authentication and platform protections.

Key areas covered

Discuss your requirement Learn more
Platforms
Android (APK or AAB) and iOS (IPA)
Approach
Static and dynamic analysis of the app, plus testing of its backend API
Reference standards
OWASP MASVS, OWASP MASTG, OWASP Mobile Top 10 (2024)
You receive
Executive summary, technical report, debrief and optional retest

Overview

About mobile application security testing

Mobile apps run on devices you do not control, and they talk to APIs that anyone with an intercepting proxy can call directly. Mobile application security testing examines both sides: what the app stores and exposes on the device, and whether the backend trusts the app more than it should.

Our testing follows the OWASP Mobile Application Security Verification Standard (MASVS) and Mobile Application Security Testing Guide (MASTG). It combines static analysis of the app package with dynamic testing at runtime, and includes the APIs your app depends on.

A typical starting point

You publish an Android or iOS app that handles logins, payments or personal data.

The security problem

Where mobile apps usually go wrong

A mobile app runs on a device you do not control, and talks to APIs that anyone can call directly.

  1. Sensitive data stored on the device

    Tokens, personal data or keys saved insecurely can be read from a lost, shared or compromised phone.

  2. Insecure communication

    Weak certificate validation lets attackers intercept or alter traffic between the app and your servers.

  3. Trusting the app instead of the server

    Security checks done only in the app can be bypassed by calling the API directly.

  4. Reverse engineering and tampering

    Hard-coded secrets and business logic can be extracted, and the app modified to skip protections.

See the security risks we see by industry

What’s covered

What we test in a mobile app

Testing is organised around the MASVS control groups, adapted to your app’s risk profile.

Area 01

Data storage and privacy

  • Sensitive data in local files, databases, logs, backups, caches and the clipboard
  • Correct use of Android Keystore and iOS Keychain
  • Data collected and shared compared with what the app declares

Area 02

Network communication

  • TLS configuration and certificate validation
  • Certificate pinning, where your risk model requires it
  • Cleartext traffic and sensitive data in transit

Area 03

Authentication and sessions

  • Local authentication and biometric implementation
  • Token storage, expiry and revocation
  • Session invalidation on logout and password change

Area 04

Platform interaction

  • Exported Android components, intents and broadcast receivers
  • Deep links, URL schemes and app links
  • WebView configuration and JavaScript bridges
  • Permissions requested compared with permissions needed

Area 05

Code quality and resilience

  • Hardcoded secrets, API keys and credentials
  • Insecure cryptography and random number generation
  • Debuggable builds and leftover test code
  • Root and jailbreak detection, anti-tampering and obfuscation, where in scope

Area 06

Backend API

  • Authorisation, business-logic and data-exposure testing of the APIs the app calls
  • Whether security checks are enforced on the server or only in the app

What you receive

What you receive from a mobile app test

One report covering the app and its backend, so findings are not split between teams.

  • Executive summary

    Overall risk and the most important issues, in plain language.

  • Technical findings

    Each issue with platform, MASVS category, CVSS severity, evidence, impact and remediation guidance for mobile and backend developers.

  • Coverage statement

    The builds, platforms, MASVS controls and API endpoints tested.

  • Debrief

    A walkthrough with your developers to discuss fixes.

  • Retest report

    If retesting is in scope, confirmation of which findings are resolved in the new build.

Sample finding

Finding 04 of 9MediumCVSS 3.1 score 5.5

Session token stored unencrypted on the device

Android app 3.4.1: shared_prefs/auth.xml

OWASP MASVS-STORAGE-1; OWASP Mobile Top 10 (2024): M9 Insecure Data Storage

What we found
The app stores its long-lived session token in plain text in the shared preferences file.
Evidence
On a test device, we extracted the app’s data folder and reused the token from auth.xml to call the API as the test user from another device. Steps and screenshots attached.
Business impact
Anyone with access to a lost, shared or compromised phone, or to a device backup, could take over the account without the password.
Fix
Store tokens in the Android Keystore and iOS Keychain, shorten token lifetime, bind sessions to the device and exclude sensitive files from backups.
Status
OpenFixed, verified at retest
Illustrative example of our report format. It is not taken from a client engagement.

Good to know

Most serious mobile issues are in the backend

An attacker does not need your app to talk to your API. If the server trusts whatever the app sends, an attacker can bypass every client-side control. That is why our mobile testing always includes the APIs the app relies on.

Before we start

What we need to test your app

We confirm the exact requirements during scoping.
  • The latest build for each platform in scope: APK or AAB for Android, IPA for iOS.
  • If certificate pinning or anti-tampering is not itself in scope, a testing build with those controls relaxed. This saves time and keeps the focus on real weaknesses.
  • Test accounts for each user role, and any test data such as payment sandbox details.
  • Access to the backend test environment, and API documentation where available.
  • A developer contact for questions during testing.

How we scope, authorise and report every engagement

Not sure you have everything?

We confirm exactly what mobile app security testing needs from your side during the scoping call, before any work is agreed.

Book a scoping call

FAQ

Questions about mobile app security testing

Straight answers to what organisations ask before they start.

Still have a question?

Ask about scope, timing or cost for mobile app security testing, even if you are not ready to commission work yet.

Contact our team

Do you need our source code?

No. We test the compiled app package, as an attacker would. Source code can make testing faster and deeper, and we can combine mobile testing with secure code review if you want white-box coverage.

Can you test an app that is already live in the app stores?

Yes. We can test the published build. For backend testing we prefer a test environment, so that we can create and change data without affecting real users.

Is it a vulnerability if our app has no root or jailbreak detection?

Not by itself. MASVS treats resilience controls such as root detection and obfuscation as defence in depth for apps with a higher risk profile, such as banking apps. We report on them according to the level of protection your app needs, not as automatic failures.

Can you test only Android, or only iOS?

Yes. Many teams test one platform in depth and the other more briefly, especially when both share the same backend. We help you decide during scoping.

How long does a mobile app test take?

It depends on the app’s size, the number of platforms and whether the backend is in scope. We provide a fixed estimate after a short walkthrough of the app.

Related services

More in Offensive & Application Security

Talk to us about mobile app security

Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for mobile app security testing.

Discuss your requirement Explore all services