Mobile App Penetration Testing: A Guide for SaaS Teams
A mobile app penetration test examines four things: the app binary itself, the data it stores on the device, the traffic between the app and your servers, and the backend API the app talks to. Most serious findings sit in that fourth layer. If a quote scopes only the app on the phone and excludes the API behind it, it will miss the majority of the risk in a typical SaaS product.
This guide is written for Australian SaaS and startup teams who have been asked for a mobile penetration test by a customer, an auditor or an app store review, and who need to know what they are buying, what the testers will need from them, and what the report will be used for.
What is mobile app penetration testing?
Mobile app penetration testing is authorised security testing of a mobile application and the services it depends on, performed by people rather than tools. Testers install your app on real or emulated devices, decompile it, inspect what it stores and transmits, intercept its traffic, and attack the backend it communicates with, all with your written permission.
The discipline has its own recognised methodology. The OWASP Mobile Application Security Verification Standard sets out what a mobile application should do to be considered secure, and the accompanying testing guide describes how to verify it. Ask any prospective provider which methodology they follow. A tester who cannot name one is improvising.
Mobile testing is genuinely different from web application testing, which is why it is quoted separately. The app runs on a device you do not control, in the hands of a user who may have deliberately rooted or jailbroken it. Anything shipped inside the app should be assumed to be readable by a motivated attacker.
What does a mobile app penetration test actually cover?
A complete mobile app penetration test covers four layers. Scoping that stops short of all four leaves gaps, and the layer most often dropped from a cheap quote is the one that matters most.
| Layer | What testers examine | Typical findings |
|---|---|---|
| The app itself | The compiled binary, its code, its resources and its resistance to tampering | Hardcoded API keys and credentials, weak obfuscation, missing root and jailbreak detection, debuggable builds |
| Data on the device | Local databases, cached files, keychain and keystore use, logs and backups | Session tokens written to disk in plain text, personal data in unencrypted local storage, sensitive values in application logs |
| Data in transit | TLS configuration, certificate validation and certificate pinning | Traffic that can be intercepted, certificate validation that can be bypassed, sensitive data in URL parameters |
| The backend API | Authentication, authorisation, business logic, rate limiting and input handling | One user reading another user’s records, missing server side permission checks, unlimited login attempts, injection flaws |
The pattern in that table is worth stating directly. Problems in the app itself are usually information disclosure, which is serious but bounded. Problems in the backend API are usually access control failures, which is how one customer ends up reading another customer’s data. For a SaaS product, the API is where the damage is.
Is web and mobile application penetration testing the same thing?
No, though they overlap. Web application penetration testing examines an application delivered through a browser, where the client is a browser you did not write and the security boundary sits at the server. Mobile application penetration testing examines an application you built and shipped to a device controlled by the user, which introduces a whole category of problems that do not exist on the web.
Three of those problems have no web equivalent. Anything compiled into your app can be extracted, so secrets in the binary are exposed rather than hidden. Data written to the device persists outside your control, including in operating system backups. Users can modify the runtime environment, so any security check performed in the app can be removed by a determined attacker.
If your product has both a web application and a mobile app sharing one backend, the API only needs testing once, but the client side work is genuinely separate. Scope them as separate pieces of work against a shared backend rather than assuming one covers the other. Our overview of the main types of penetration testing sets out how the categories relate.
What do testers need from you before a mobile app penetration test?
The most common cause of a thin mobile penetration test report is an incomplete handover at the start. Testers who cannot install the app, cannot log in, or cannot reach a non production environment spend the engagement working around access problems instead of finding vulnerabilities.
Prepare the following before the testing window opens:
- Installable builds for every platform in scope, ideally non production builds that point at a test environment rather than at live customer data.
- Test accounts at more than one permission level, because authorisation flaws are only findable when a tester can attempt to act as one user against another user’s data.
- API documentation, even if it is incomplete, along with any Postman collections or schema files you already have.
- A named technical contact who can answer questions during the testing window without a three day delay.
- Written authorisation covering the testing, plus confirmation of anything explicitly out of scope such as third party services you do not own.
On that last point, be aware that testing infrastructure you do not own generally requires the owner’s permission. If your app depends on third party services, agree the boundary in writing before testing starts.
How long does a mobile app penetration test take?
A mobile app penetration test is usually delivered over several weeks from first call to closed findings, with the actual testing window forming a small part of that. The scoping conversation, the access handover, your remediation work and the retest all take time, and remediation is normally the longest phase because it depends on your development cycle.
Two variables drive the testing window itself: how many platforms are in scope, since iOS and Android are separate pieces of work, and how much functionality sits behind authentication. An app with a single sign in screen and a read only feed is a much smaller job than one with payments, messaging, file sharing and role based permissions.
Build the retest into your plan from the beginning. A report full of open findings is of no use in an enterprise sale. A report showing findings identified and verified as remediated is exactly what a procurement team wants to see, and our step by step preparation checklist covers the groundwork that keeps an engagement on schedule.
Do Australian SaaS companies need mobile app penetration testing for compliance?
No framework in common Australian use names mobile application penetration testing as a specific requirement. What ISO 27001 and SOC 2 both expect is that you identify technical vulnerabilities in the systems you operate and act on them. If a mobile app is a significant part of your product, an auditor will reasonably expect it to be within the scope of your testing programme.
In practice the stronger driver is commercial rather than regulatory. Enterprise buyers running a security review will ask when your app was last tested, by whom, and what was found. So will many cyber insurers. A recent test against a named methodology answers all three questions at once and shortens the security review considerably.
If you also hold personal information through the app, your obligations under the Australian Privacy Act sit alongside all of this. The Notifiable Data Breach scheme requires eligible breaches to be reported, and testing is one of the reasonable steps that helps prevent you having to. Our guides to penetration testing for ISO 27001 and penetration testing for SOC 2 cover what each auditor expects to see.
Common questions
What is mobile app penetration testing?
Mobile app penetration testing is authorised security testing of a mobile application and its supporting services by human testers. It covers the app binary, data stored on the device, network traffic and the backend API. The goal is to find exploitable vulnerabilities before an attacker does, and to produce evidence you can act on and show to customers.
What is mobile application security testing?
Mobile application security testing is the broader category covering both automated tooling and manual penetration testing of mobile apps. Automated tools scan a binary or a running app for known issues quickly and cheaply. Manual penetration testing adds human reasoning about your business logic, which is what finds authorisation flaws. Most mature programmes use both.
How do you do mobile application penetration testing?
Testers install the app on real or emulated devices, decompile the binary to inspect code and embedded secrets, examine what the app writes to device storage, intercept and manipulate its network traffic using a proxy, then attack the backend API directly. Work is normally structured against a recognised methodology such as the OWASP mobile testing guide.
Is there a mobile app penetration testing checklist?
Yes. The OWASP Mobile Application Security Verification Standard is the most widely used, setting out verification requirements across storage, cryptography, authentication, network communication, platform interaction, code quality and resilience. It is publicly available and worth reviewing before you scope a test, because it helps you judge whether a proposed scope is complete.
What is application penetration testing?
Application penetration testing is authorised testing of software applications, as distinct from testing networks or infrastructure. It covers web applications, mobile applications and APIs. The focus is on flaws in the application itself, such as broken access control or business logic errors, rather than on missing patches or misconfigured servers.
Should we test both iOS and Android?
If you ship both, yes. The platforms differ in how they store data, how they handle credentials, and what protections the operating system provides, so a finding on one does not reliably indicate the same finding on the other. Testing both costs more than testing one, and testing only the more widely used platform leaves a real gap.
Get your app tested properly before a customer asks
Siege Cyber is a CREST accredited Australian penetration testing firm. We test mobile apps and the APIs behind them, and we scope engagements so the report is something you can hand to an enterprise buyer. See our penetration testing services, or read why CREST accreditation matters when you are comparing providers.
If your customers are asking broader security questions, our SOC 2 and virtual CISO services cover the rest of that conversation.
Get in touch and we will scope it with you.