Testing mobile apps
The app, its local storage and the backend behind it, tested along the OWASP MASVS. On a device the attacker controls.
The app runs on somebody else's device
A mobile app runs where you have no control. The user can unlock the device, take the app apart, read the traffic and read out the storage. For testing, that is the starting point, not the exception.
We test along the OWASP Mobile Application Security Verification Standard, for Android and iOS. The standard also sets the depth of testing, which makes it usable as evidence towards your own customers.
Credentials in local storage
The app authenticates, receives a token and stores it. Whether that lands in the operating system keychain or in a file next to the database cannot be seen from outside.
On a device with elevated privileges it can be checked. If a long-lived token, a password or a key turns up there in the clear, access to the backend is transferable, and the login in the app becomes a formality.
That is why the backend belongs in every app test. What the app checks is beside the point if the same interface does not repeat the check.
Eight areas, three that decide it
The standard names eight requirement areas. In practice, three of them decide how a test turns out.
Data on the device
Storage and privacy, cryptography, key management. What lies unencrypted in files, databases, the clipboard, logs and backups.
Authentication and connection
Authentication and session management, network communication, certificate validation. Whether the traffic can be read with a certificate of our own decides the rest of the test.
Platform and resilience
Interaction with the operating system, permissions, links between apps, code quality and build settings, plus protection against tampering and analysis.
How an app test runs
The effort follows the number of platforms and roles. Testing follows the OWASP MASVS; every report goes through a second-pair-of-eyes review.
Scope and credentials
Which platforms, which roles, with or without source code. We need one set of credentials per role and a build or a test distribution; publication in a store is not a condition.
Prepare the device
The app runs on a device with elevated privileges, because that is an attacker's starting point. The traffic is read with a certificate of our own, as far as the app allows.
Test along the MASVS
Storage on the device, authentication and connection, platform and resilience. Alongside it the backend, because what the app checks is beside the point if the interface does not repeat the check.
Report and retest
Findings with reproduction steps and a rating against the agreed scheme, separated by platform. On request the check after the fixes.
Common questions about app testing
Not necessarily. Without source we work with the built app; with source we get further and faster. For your own developments the second route is usually the more economical one.
The test runs per platform, because storage, permissions and protection differ. The backend we test once.
We test on a file you provide or on a test distribution. Publication in a store is not a precondition.
Certifications and memberships.
Talk to us.
A first conversation usually takes 30 minutes. We look at where you stand and tell you frankly whether we are the right partner.