iOS Security Assessment (MSTG)

It evaluates an iOS app for security weaknesses — insecure storage, weak cryptography, flawed authentication and biometrics, weak network protection, unsafe platform interactions, and thin resilience — measured against the OWASP MASVS and its testing guide, the MASTG, with each finding proven and rated.

MASVS is OWASP's standard of what a secure mobile app must do, grouped into control areas and verification levels. The MASTG is the testing guide that shows how to verify those controls; it is the current name for what used to be called the MSTG. We assess against MASVS and test with the MASTG.

iOS offers the Keychain for secrets and Data Protection classes that tie file encryption to the device being unlocked. We check that sensitive data uses them correctly and does not leak elsewhere — into plists, logs, the pasteboard, screenshots, or unencrypted backups — which is where mobile data exposure most often happens.

The question is whether biometrics gate something real or are only a UI check. Done well, a successful biometric unlocks a key held in the Secure Enclave; done poorly, the app just shows a prompt and continues if it returns success, which runtime instrumentation can bypass. We test which of the two it is, and whether sensitive actions are also enforced on the server.

It is defense in depth, not a substitute for the other controls. Jailbreak detection, anti-tampering, and anti-debugging raise the effort for an attacker, but a determined one can bypass them, so they must sit on top of correct storage, cryptography, and server-side authorization — never replace them. We test how far the resilience holds and, more importantly, what is exposed once it is bypassed.

The app as an IPA or TestFlight build, test accounts for each role, and agreement on whether the backend and APIs are in scope. Source access (a white-box or grey-box engagement) makes the review deeper and faster, but we can also test from the compiled app alone. We agree the scope before we begin.

Each finding gets a CVSS score for a common baseline, adjusted by the real impact in your context — what data or action it exposes, and whether it needs a jailbroken device or physical access. That is why a hardening gap and a data-exposure flaw with the same CVSS can be prioritized differently.

Yes. After you remediate, we re-test the reported findings to confirm each fix holds and did not introduce a new issue, and we update their status in the report.

It depends on the size of the app, the features it uses, and whether the backend is in scope; a typical assessment runs about two to four weeks. We give a firm estimate after scoping.