Skip to content
SecuriFii

Technical testing

Mobile Application Security Testing

A mobile app is a client you have handed to every user, on a device you do not control. Anything it stores, anything it trusts and any check it performs locally can be read, altered or bypassed. Testing one properly means taking it apart, running it on a device under the tester’s control, and then testing the server it talks to.

Discuss this
Standard
OWASP MASVS v2.1 · MASTG v2
Control groups
8
Testing profiles
L1 · L2 · R · P
Platforms
Android · iOS
Retest
Included

What the standard covers, and what it leaves to you

The OWASP Mobile Application Security Verification Standard, MASVS, is the requirement set: version 2.1.0, released in January 2024, organises twenty-four controls into eight groups — storage, cryptography, authentication and authorisation, network communication, platform interaction, code quality, resilience against reverse engineering, and privacy. The Mobile Application Security Testing Guide, MASTG, is the method: individual tests for Android and iOS, each mapped to the control it verifies.

Version 2 of the MASVS removed the old L1, L2 and R levels from the controls themselves and moved them into the MASTG as testing profiles — MAS-L1, MAS-L2, MAS-R and, since 2025, MAS-P for privacy. A profile states who the attacker is: other apps on the device for L1, an untrusted operating system and physical access for L2, the user themselves for R. Choosing one is a threat-model decision, and it changes what is tested.

The MASVS is explicit that it covers the app only. It contains no controls for the remote endpoints, and the MASTG does not test them; OWASP points to the ASVS and the Web Security Testing Guide instead. We include the backend API in scope by default, because an app that stores nothing and checks everything on the server is only as strong as the server.

What it will ask of you

OWASP recommends an open-book review for MASVS verification, and the reasons are practical. These four decide the quality of the result.

  • Builds for both platforms

    An Android package and an iOS build the tester can install, ideally without release obfuscation unless resilience is what is being tested. Store builds alone limit what static analysis can see.

  • Test accounts for each role

    At least one account per role, on an environment we may test. Authorisation failures in the API are found by trying one user’s data from another user’s session, which needs two accounts.

  • A profile decision

    L1 for most apps, L2 where the app handles high-risk data or sensitive functionality, R where the business logic itself needs protecting. Agreeing it up front decides which tests are in scope.

  • Authority over the backend

    Written authorisation for every API host the app talks to, including any run by a third party. Testing the API is in scope only where you can demonstrate the authority to permit it.

What it is used for

  • Pre-release assurance for a new app or a major version, before it reaches the stores.
  • Evidence for ISO/IEC 27001 and SOC 2 that technical testing covers the mobile channel.
  • Customer, partner and regulator requests that name the OWASP MASVS or a MAS profile.
  • A ranked remediation list across the app and its API, owned and closed with a retest.

Not sure this is the standard you need?

Tell us what triggered the question — a customer, an auditor, a contract clause — and we will say which of these applies, including when the answer is none of them.

Ask a practitioner

Where we come in, and where we stop

We are the assessor here, with no third party behind us, exactly as for any penetration test. What we will not do is test an app we built, or a control we designed, and call the result independent. And OWASP does not certify apps or testers against the MASVS: a report stating which controls were verified is what we provide, and a “MASVS certified” badge is not something anyone can honestly issue in OWASP’s name.

Ours

  • Scope, the MAS profile and the rules of engagement
  • Static and dynamic testing on Android and iOS
  • Testing the backend API the app depends on
  • The report, remediation guidance and the retest

Yours

  • Builds, test accounts and authority over every in-scope host
  • Fixing the app and the API, with our support
  • App store review, which belongs to Apple and Google

How an engagement runs

Testing proceeds only under written authorisation naming the app builds, the API hosts, the test window and the rules of engagement. We do not test a backend you cannot demonstrate authority over.

  1. 01Scope, profile and authorisationAgree the builds, platforms, API hosts, test accounts and the MAS profile, and what is explicitly out of bounds. You sign an authorisation covering every host.
  2. 02Static analysisUnpack and decompile the builds. Look for hardcoded secrets, insecure storage, weak cryptography, exported components, permissions requested, third-party libraries with known vulnerabilities, and build settings left in debug.
  3. 03Dynamic analysisRun the app on test devices, intercept its traffic, and observe what it writes to storage, logs and backups. Where the profile calls for it, test on rooted and jailbroken devices and against tampering.
  4. 04Backend API testingExercise the API the app uses with each role’s credentials — object and function-level authorisation, authentication and session handling, and what the server returns that the app never displays.
  5. 05ReportingFindings mapped to the MASVS control and the MASTG test that found them, with severity, reproduction steps, evidence and remediation per platform. A statement of what was not tested, and why.
  6. 06Remediation support and retestWe retest the fixed builds and the API and issue a retest letter, finding by finding, that you can hand to a customer or an auditor.

What you get from us

  • Executive summary written for a non-technical reader
  • Findings mapped to MASVS controls and MASTG tests, with severity and evidence
  • Remediation guidance specific to Android and iOS, not generic advice
  • Backend API findings in the same report, ranked on the same scale
  • A statement of the profile tested, the builds, and what was out of scope
  • Retest of remediated findings and a retest letter for third parties

Common questions

What is the current version of the OWASP MASVS?

Version 2.1.0, released in January 2024, which added the MASVS-PRIVACY group to the seven groups introduced in version 2.0.0. It has eight control groups and twenty-four controls.

What happened to MASVS L1, L2 and R?

Version 2.0 moved them out of the standard and into the MASTG as testing profiles, so that one control can be tested differently depending on the threat. MAS-L1, MAS-L2 and MAS-R remain, and MAS-P was added for privacy.

Do you test the backend API as well as the app?

Yes, by default. The MASVS covers the app only and says so; the authorisation decisions that protect your users’ data are made on the server, so a test that stops at the app misses the part that matters most.

Do you need source code?

Not necessarily. The builds are enough for static and dynamic analysis, and that is how most mobile tests run. Source access lets us confirm a finding’s cause and reach code paths that are hard to trigger, and OWASP recommends it for MASVS verification.

Will passing the test get our app through store review?

No. App store review is Apple’s and Google’s, against their own guidelines, and it is a different question from whether the app is secure. A clean security report and a rejected submission can coexist.

Ready to scope it?

Send the date you are working to and roughly how large the organisation is. You will get a reply from a practitioner with an honest read on whether the date is reachable.

Start the conversation

Related services

  • API Security Testing

    Find the request that returns somebody else’s data — the flaw that leads the OWASP API Security Top 10 and the one an automated scanner cannot recognise.

  • Vulnerability Assessment and Penetration Testing (VAPT)

    Find what an attacker would find, ranked by what it would actually cost you — and get a report your auditor and your engineers can both use.

  • Secure Code Review

    A reviewer reading your code for the flaws a scanner cannot see — with the scanner’s output triaged rather than forwarded.

All services

Related insights

All insights