A web pentest can be thorough and accurate and still miss your mobile app entirely. These five vulnerabilities live in the app binary, on the device, or in API versions that only older installs still call, so web testing cannot reach them.
Follows on from Why autonomous security testing stops at the browser.
Every mobile app in production is really several apps. There is the current version, and then there is every older version still installed on phones whose owners never update. You can encourage people to upgrade. On most products, You can enforce a minimum version, but many products choose not to block old installs.
That single fact explains a lot of what goes wrong on mobile, and it is a good place to start.
In the previous piece I set out what a real mobile assessment has to reach: the binary, the runtime and the traffic, on both platforms. That piece was about coverage. This one is about what turns up once you have it. These are the categories of finding that came up again and again across Cyrex's mobile engagements, and that a web test, however thorough, could not have seen.
Mobile vulnerabilities web testing can't reach
1. Deprecated API versions still live for old app installs
Because old app versions stay installed, the endpoints they call stay live. The web client moved to the current API long ago. The mobile client from two years back still calls the previous one, and that version often predates fixes the current API received. Authorisation checks added later were never backported, because nobody thought of the old version as a product any more.
A web test exercises the API the web client uses. It has no reason to know the older version exists. You find it by reading the binary of an older build and seeing what it calls.
2. Hardcoded API keys and secrets in the app binary
API keys for third party services, internal hostnames, staging URLs, occasionally credentials. They were put in the app for convenience during development and shipped to every phone that installed it. Anything inside a binary should be treated as public, because anyone with the app can extract it.
This is invisible from the network boundary. Some of these secrets never cross the network, so traffic-based testing cannot see them. It only needs to be inside the file.
3. Tokens and session data that survive logout
The user taps log out. The interface returns to the login screen. On the device, the refresh token is still sitting in local storage, or the cached account data is still on disk, or both. Anyone with physical access to the device, a backup of it, or a rooted or jailbroken phone can recover that data, and if it was written to shared storage, other apps can read it too.
The server may invalidate the session correctly, but cached personal data is still on disk. Often the refresh token is not revoked server side either, so the leftover copy still works.
4. Exported components and deep links other apps can abuse
Mobile apps expose entry points to the rest of the operating system: deep links, URL schemes, and on Android, exported components that other apps can call directly. When one of those triggers an authenticated action without checking where the request came from, a malicious app on the same phone can drive the target app on the user's behalf.
The closest web analogue is CSRF, but the mechanics are platform specific and need mobile-specific testing. It is a property of the platform, and it can only be tested on the platform.
5. Client-side checks on purchases and premium features
Premium features unlocked by a flag the app checks locally. Purchase validation done on the device. Limits applied by the interface rather than the server. If the rule lives on the client, the user controls it, because the user controls the device.
This one came up most in games, where in-app purchases and economies made it valuable to get around. It is not a games problem. Any app that gates paid features or enforces limits can make the same mistake, including fintech and subscription products.
Why a clean web pentest doesn't cover your mobile app
Look at the five together and two things stand out.
First, none of them is exotic. They are not novel attack techniques. They are ordinary mistakes made by competent teams under deadline pressure, and most of them would be caught in code review if anyone were reviewing the mobile client with security in mind.
Second, every one of them is invisible from where most testing stands. A web assessment, an API scan or a review of the backend can all be thorough and accurate, and still report nothing on any of the five. The report is not wrong. It is describing a different application from the one your users have installed.
For a security leader, that is the useful question to ask of a clean report. Not whether the test was good, but whether it ever touched the client your customers actually run, and which versions of it.
What mobile app testing can and can't tell you
These are categories, not statistics. I have deliberately not said how often each one appeared. Rates from one firm's engagements depend heavily on who that firm's clients were, and a percentage would suggest a precision this piece does not have.
A skilled mobile tester finds all of these. Nothing on this list needs autonomous testing to discover. An experienced engineer with the right tooling and enough time will find every one. The problem has never been that these flaws are hard to find. It is that mobile clients are rarely tested at all, and when they are, it is once a year against the current build only.
Fixing them is mostly on you. Old API versions need a deprecation plan. Secrets need moving server side. Client-side rules need rebuilding on the server. Testing tells you where the problem is. It does not make the product decision about which old users you are willing to break.
Where Deus Rex sits
Deus Rex tests web, iOS and Android, across the binary, the runtime and the traffic, and it is in use on live mobile engagements now. The five categories above are the kind of thing it is built to look for, on every build rather than once a year.
The list itself is not new to us. Cyrex spent twelve years testing software for studios and enterprises that shipped on mobile, desktop, console and web at the same time, to millions of users, some of whom were actively trying to break it. These were the findings that kept coming back. Deus Rex is how we stopped having to find them by hand, one engagement at a time.
If you have a clean report on your web application and have never had your mobile client tested, that gap is worth a conversation.
deusrex.ai
Written by
Tim De Wachter
CTO Deus Rex
