OWASP MASVS coverage
MASVS sets out security requirements for storage, cryptography, authentication, network traffic, platform interaction, code quality and resilience. We test each area that applies to your app.
OWASP MASVS-aligned testing of your iOS and Android apps and the APIs behind them. Vectra holds the CREST Mobile App Security Testing accreditation, and our testers are based in Australia.
Mobile app penetration testing examines an iOS or Android app the way an attacker would: by pulling the app apart, watching it run on a compromised device and attacking the services it talks to. Vectra offers mobile app penetration testing across Australia, and Mobile App Security Testing is one of our six CREST accreditations. We assess apps against the OWASP Mobile Application Security Verification Standard (MASVS) and its testing guide (MSTG). Static binary analysis, runtime hooking with Frida and Objection, and testing of the back-end API are all part of the scope. Every High-and-above issue is exploited by hand before it reaches the report.
The essentials of a Vectra mobile engagement. The detail is set at scoping, around your app, platforms and back end.
iOS and Android, tested separately or together in one engagement.
CREST Mobile App Security Testing, one of Vectra's six CREST accreditations.
OWASP MASVS and its testing guide (MSTG).
Static binary analysis, reverse engineering, anti-tamper review and runtime hooking with Frida and Objection.
API assessment bundled into the mobile scope.
A mobile app runs on hardware you do not control. We test it as though the attacker holds the device.
MASVS sets out security requirements for storage, cryptography, authentication, network traffic, platform interaction, code quality and resilience. We test each area that applies to your app.
We decompile the app to look for hard-coded keys, secrets, debug code, weak cryptography and logic that should never have left your developers' machines.
Using Frida and Objection, we intercept functions while the app runs, alter return values and switch off client-side checks to expose what the app trusts.
We inspect what the app leaves on the handset: files, databases, caches, logs, screenshots, the iOS Keychain and the Android Keystore.
We intercept traffic between app and server, check TLS configuration and test whether certificate pinning stops a man-in-the-middle attack.
We assess how easily an attacker could repackage the app, bypass integrity checks or run it on a jailbroken or rooted device.
Deep links, Android intents, WebViews, clipboard use and permissions can all expose data to other apps. We test each one your app uses.
We call the app's API directly, outside the app, to find authorisation gaps and data exposure that the mobile interface never reveals.
Mobile apps change quickly and travel everywhere. These moments call for a test.
Before the first release to the App Store or Google Play.
Before any release that changes sign-in, payments or local data storage.
When the app holds passwords, health information or other regulated data.
When the app takes payments or stores card details.
After adding a third-party SDK or changing the back-end API.
When a bank, partner or enterprise customer asks for independent evidence.
Mobile testing needs its own tools and techniques. This is what we bring to it.
A specific CREST accreditation for mobile work, separate from our general penetration testing accreditation. You can verify it on the CREST Marketplace.
When your app ships on both platforms, we can test both builds side by side and report shared weaknesses once, with platform-specific fixes.
Backend API assessment is bundled into mobile testing, so a flaw that starts on the handset and ends in your database is traced end to end.
Frida and Objection let testers change the app's behaviour while it runs, which reveals what static review and automated scanning cannot.
Our six CREST-aligned steps, as they apply to a mobile application and its back end.
We agree the platforms, app versions, test builds, back-end environment and user roles, and confirm how builds will be shared.
We consider who might attack the app: a thief holding the phone, malware on the device, or someone intercepting traffic on public Wi-Fi.
We decompile and inspect the binary, listing embedded secrets, third-party SDKs, exported components and the endpoints the app calls.
Testers hook the running app, bypass client-side controls and attack its storage, transport and API calls against the MASVS requirements.
We show what an attacker gains from a compromised app, such as other users' accounts, payment functions or back-end data.
Findings are reported per platform with fixes for each, followed by a retest once your developers ship a corrected build.
Mobile findings often differ between iOS and Android, so our report shows clearly which platform and build each issue affects.
You also receive the deliverables that come with every Vectra engagement, set out on our penetration testing page.
Each issue is tagged by platform and build, with reproduction steps and screen captures of the exploit chain.
Developer-ready remediation for iOS and Android, with a suggested code fix where one applies.
A narrative report for leaders and a walkthrough with your mobile and back-end developers.
A retest window for High-and-above findings, plus 90 days of portal access to track remediation.
Mobile apps often carry the most sensitive data a business holds. A test supports the frameworks that govern it.
Mobile banking and payment apps are core systems for APRA-regulated entities, and CPS 234 expects their security controls to be tested.
Apps inside your cardholder data environment fall under requirement 11.4 testing. Payment SDKs can be assessed under the PCI Secure Software Standard.
Patient apps hold health information, which the Privacy Act treats as sensitive. Testing local storage and the API protects it.
Shopping and loyalty apps combine stored accounts, saved cards and promotions, which makes them an attractive target for fraud.
Testing each significant release supports Annex A control 8.29, security testing in development and acceptance.
Citizen-facing apps for federal, state and local government handle identity and personal data that must be protected.
Platforms, user roles and the size of the back-end API shape the effort, so each app is scoped and quoted individually.
A mobile app is the visible part of a bigger system. These tests cover the rest of it.
A deeper look at the API your app calls, including partner access, GraphQL and gRPC services.
The customer website or portal that often shares accounts and data with your mobile app.
The cloud accounts, storage and functions that host your mobile back end.
Every type of test we run, our methodology and our CREST accreditations.
Our city pages cover the sectors, compliance needs and procurement routes that matter to app teams in each location. Each one also lists the local office contact details.
A test build gives the best results. For Android, send an APK or app bundle; for iOS, share an IPA or invite our testers through TestFlight. Point the build at a test environment and provide accounts for each user role. If a test build is not possible, we can assess the public store version, although some checks then take longer.
Yes. Where an app ships on both platforms, testing them together usually makes sense. The two builds often share an API and business logic but differ in how they store data, handle certificates and detect tampering. Testing them side by side lets us report common issues once and give platform-specific fixes where the builds diverge.
Test before each release that changes sign-in, payments, data storage or the API the app depends on. Minor interface updates rarely need a full retest. Many organisations also test at least once a year, and apps that hold passwords, regulated data or payment details may need testing more often.
Yes. Back-end API assessment is part of our mobile app scope, because that is where most of the valuable data sits. Attackers can bypass any check the app performs on the device and call the API directly. If the API also serves a website or partners, our API penetration testing page explains how we test it on its own.
Yes. We test whether those controls can be bypassed, since a determined attacker will try. For the rest of the assessment, we either bypass them or ask for a build with them switched off, so the time goes on testing the app rather than fighting its defences. Both results appear in the report.
Speak to us about your cyber governance and compliance requirements.
Message sent
A member of our team will be in touch soon at . You can also reach us during business hours on 1800 816 044.
Need us sooner? Call +61 8 8208 0800, or the 24/7 incident line on 1800 816 044 if something is happening now.