The real sequence of an iOS or Android engagement, from the rules of engagement to the retest, including what this kind of test deliberately does not cover.
A mobile application penetration test is a manual assessment of an iOS or Android app and the backend it talks to, run from the position of somebody who downloaded your app onto a device they fully control.
That last clause is the whole discipline. Once a build reaches a store the attacker owns the runtime: they take it apart offline, install it on unrestricted hardware, hook it as it runs and replay what it sends, none of which touches your infrastructure.
So the test does not answer "is the app secure", but three narrower questions: what can somebody extract from the build, what can they bypass on the device, and what does that let them do to your server.
Nothing technical starts until the scope is on paper: which apps, which platforms, which build identifiers, which backend environment, which test accounts, and what we may do to each.
The rules of engagement matter more here than clients expect, because the work has two halves with very different blast radii. Taking a build apart on our hardware touches nothing of yours. Following the token we found inside it into your API does. NIST SP 800-115 defines rules of engagement as the document that "gives the test team authority to conduct defined activities without the need for additional permissions". The backend half needs agreed windows, agreed rate limits and a named contact first.
The first technical phase needs nothing running. We open the .apk, .aab or .ipa: manifest or Info.plist, compiled code, resources, bundled SDKs and every string that shipped by accident.
iOS and Android are scoped separately, because a flaw on one is often absent on the other. Android’s Network Security Configuration lets an app choose its trusted certificate authorities, opt out of cleartext traffic and pin certificates; for apps targeting Android 9 (API level 28) and higher the default sets cleartextTrafficPermitted to false. App Transport Security operates by default for apps linked against the iOS 9.0 SDK or later, requiring TLS 1.2 or later and forward secrecy through ECDHE. Both can be loosened in a few lines, and this is where you find out.
This phase belongs to mobile and nothing else. The build goes onto a rooted or jailbroken handset and we watch it work. MASVS-RESILIENCE-1 states the premise better than we can: "Running on a platform that has been tampered with can be very dangerous for apps, as this may disable certain security features." So we tamper with it deliberately, then examine what the app assumed it could trust.
Now the app talks and we need to read it, which means defeating certificate pinning on a device we already control. That bypass is not a finding by itself. It is the entry ticket to the half of the engagement where the damage lives.
Server-side the work is what an API engagement covers, scoped to the surface the app calls. It starts with broken object level authorisation, first on the OWASP API Security Top 10 2023: change the identifier in a request from your object to somebody else’s and see whether the server checks. Broken function level authorisation, unrestricted resource consumption and improper inventory management sit on the same list.
Those chains rarely end in the app: the same object identifiers reach the API, and the API reaches whatever the cloud account behind it can.
Until now we hold candidates. Exploitation turns a candidate into a fact, and it is what separates a pentest from a scan. NIST SP 800-115 draws the line: "While vulnerability scanners check only for the possible existence of a vulnerability, the attack phase of a penetration test exploits the vulnerability to confirm its existence."
A key in the binary is a note. A key that still authenticates against a production endpoint, which then returns another customer’s records, is an incident somebody has not had yet. So each candidate is carried as far as it goes, and the phases loop: the four-stage model in NIST SP 800-115, planning, discovery, attack and reporting, has a documented feedback path from attack back into discovery.
Every working step is captured so your engineers can replay it: request and response, instrumentation script, device state, build identifier.
Severity is scored with CVSS, maintained by FIRST. A base score is intrinsic technical severity, constant across environments and over time, and the specification is explicit that it feeds a risk process weighing regulatory exposure, customer impact and business loss too. Findings are ranked by what they reach in your environment.
Then the retest. A finding is closed when the original proof of concept stops working against the fixed build, re-run on the same devices with the same steps. That catches the fix aimed at the demonstration rather than the pattern, and the fix that landed in the app while the server kept accepting the old request. Every Asperis engagement includes it at no extra cost.
A single-platform app is typically one to two weeks of active testing. Both iOS and Android, or a complex backend inside the scope, runs to two or three weeks. Scoping happens before that window opens and the retest follows your fixes.
What moves it: platforms in scope, how many authenticated roles there are, the size of the API surface, whether the app handles payments, identity or health data, and whether resilience controls must be defeated first.
The OWASP Mobile Top 10 2024 is an awareness list rather than a methodology; findings are mapped onto it because your stakeholders have heard of it. For apps you procure rather than build, NIST SP 800-163 Revision 1, "Vetting the Security of Mobile Applications", April 2019, is the companion process.
If a supplier says their mobile test covers all six, ask which of the six they are quietly not doing.
Every framework reference and platform default above comes from one of these.
The real sequence of an external network penetration test: scope and rules of engagement, reconnaissance, perimeter analysis, exploitation, reporting and retest, plus what the test will not cover.
The sequence of a real internal network penetration test: the starting point we agree, what a domain account becomes, what you get at the end, how long it takes and what the exercise deliberately does not cover.
The seven phases of a web application penetration test, what has to be ready before day one, how long it runs, what lands in your inbox at the end, and the things it deliberately does not cover.
If any of this looks like a problem you are carrying, half an hour on a call scoping it with a senior pentester is worth more than reading another article.
Hablar con un pentester seniorPick a time that suits you. You tell us what you need and where you are, and we explain how we work and how we can help.
