Dit artikel is alleen in het Engels beschikbaar.
A mobile app is two things at once: a client you hand to the user, and a set of API calls you cannot see from the outside. Testing it well takes two views. Static analysis reads the app itself; dynamic testing watches it while it runs. Neither is complete alone. This post covers what each reveals, following the structure of the OWASP Mobile Application Security Verification Standard.
Static analysis: reading the app
Static analysis takes the app package apart and reads what is inside, without running it. It is fast and it finds the mistakes that ship inside the build.
The recurring findings are consistent across platforms: secrets hardcoded into the app, such as API keys or credentials; sensitive data written to insecure local storage rather than the platform keystore; weak or custom cryptography where a standard library should be used; and components exported to other apps on the device without the access checks they need.
Anything shipped inside the app is not a secret; a hardcoded key is a published key.
The fix follows the findings: keep secrets out of the client, store sensitive data in the platform’s protected storage, use the platform’s cryptography rather than a homemade scheme, and expose only the components that must be shared, with proper checks.
Dynamic testing: watching it run
Dynamic testing runs the app against its real backend and watches the behaviour. The most valuable target is the traffic, because a mobile app is only as secure as the API it talks to.
The first check is whether the traffic can be intercepted. An app that does not validate its server certificate, or that can be persuaded to accept an interception certificate, exposes its entire API conversation. Certificate pinning raises this bar, and part of a test is confirming that pinning is present and correctly enforced rather than assumed.
Once the traffic is visible, the API itself is in scope, and mobile backends share the same weaknesses as any API: authorisation on individual objects, token handling, and data exposure. A mobile test that stops at the app and never reaches the API has tested half the system.
The two views together
| View | What it reveals | Example finding |
|---|---|---|
| Static | Flaws built into the app package | Hardcoded key, insecure storage, weak crypto |
| Dynamic | Flaws in behaviour and traffic | Interceptable traffic, weak pinning, API authorisation gaps |
The two overlap by design. A hardcoded key found statically is confirmed dynamically when it is seen in a live request. A pinning weakness found dynamically explains why the static secret is reachable at all. The finding is strongest when both views agree.
Closing
Mobile testing is not one activity but two, and the interesting results usually sit where they meet: an app that leaks something it built in, reaching an API that trusts it too much. A complete assessment reads the app, watches it run, and follows the traffic all the way to the backend.
For how mobile testing is structured, see the mobile application security service page.
