Authentication Flaws

Authentication testing on iOS concentrates on where the decision is taken. The platform offers strong local authentication and hardware-backed key storage, but both can be used as a gate that merely returns a result rather than as a lock that releases a key — and only the second survives an attacker with the device.

What an attacker is trying to achieve

The attacker controls the device and can instrument the running application. Any check evaluated there can be made to return success. They want the application to have relied on that result, rather than on something the device cannot produce without the user.

Test cases

5 test cases in this category. Each states what the test proves, how it is carried out, what has to be in place beforehand, what a positive result looks like, and whether the work is manual, automated or a mixture.

IOS-AUTH-01 Insecure Authentication Vectors

Objective — Determine whether identity is established from device-derived values, which the device's owner can change, forge or transfer.

How it is tested — Identify every value the client sends that contributes to identifying the user or installation, including vendor and advertising identifiers and any value derived from device characteristics. Establish which the server treats as authenticating rather than merely descriptive. Substitute values from another installation and from another account, and observe whether the server accepts them. Test whether such a value alone grants access.

Prerequisites — Two devices or installations with distinct identifiers; two accounts; a proxy able to modify requests; the decrypted binary.

Indicators — A device identifier accepted as authentication; access granted after substituting another installation's identifier; identity bound to a value the client controls.

Coverage — MASVS-AUTH-1MASVS-AUTH-2CWE-287CWE-290

Depth — Manual Requires substituting values between real installations to separate descriptive from authenticating.

IOS-AUTH-02 Cross-Application Authentication

Objective — Determine whether authentication shared across the vendor's applications, or delegated to another application, can be abused by a participant that should not be trusted.

How it is tested — Identify how authentication state is shared: a keychain access group, a shared App Group container, or a token returned through a URL scheme. Establish what verifies the peer in each case. From a test application, attempt to read the shared state or to receive the returning token by registering a competing scheme. For delegated sign-in, establish whether the response is bound to the request that began it.

Prerequisites — The bundle entitlements; the vendor's related applications; a device; a test application able to register competing schemes.

Indicators — Shared authentication state readable by another application; a returning token interceptable; a delegated response accepted without binding to its request.

Coverage — MASVS-AUTH-1MASVS-PLATFORM-1CWE-287CWE-939

Depth — Manual Requires a second application competing for the same schemes or groups.

IOS-AUTH-03 Local Authentication Bypass

Objective — Determine whether the on-device biometric or passcode check is used as a gate returning a result, or as a lock releasing key material, since only the latter resists an attacker holding the device.

How it is tested — Establish what the local check protects and whether the protected material is stored under an access control that requires the authentication, or merely retrieved after a successful result. Instrument the running application to force the success path without authenticating, and observe whether the protected function proceeds. Establish whether the result is asserted to the server as a claim it trusts.

Prerequisites — A device permitting instrumentation; biometric or passcode enrolment; the decrypted binary; a proxy to observe what the server is told.

Indicators — The protected function proceeding when the check is forced to succeed; protected material retrievable without the authentication; a client-asserted local result trusted by the server.

Coverage — MASVS-AUTH-2MASVS-AUTH-3CWE-287CWE-603

Depth — Manual The distinction between gate and lock is only visible by instrumenting the running application.

IOS-AUTH-04 Client-Side Authentication Flaws

Objective — Determine whether any part of the authentication decision is taken by the client and accepted by the server without independent verification.

How it is tested — Hook the authentication methods in the running application — the delegate callbacks and completion handlers that carry the outcome — and force each to report success, then observe whether the server ever notices. Establish whether the session the application ends up holding was issued by the server or assembled locally. Check whether attempt counting, credential format validation or second-factor verification happens only on the device, and whether sign-in state persisted in the keychain can be reinstated without contacting the server at all.

Prerequisites — A device permitting method hooking in the running application; a proxy with interception; keychain and container access; an account whose sign-in can be repeated freely.

Indicators — A forced success handler producing a usable session; a session assembled locally rather than issued; attempt counting only on the device; keychain state alone restoring an authenticated session offline.

Coverage — MASVS-AUTH-1MASVS-CODE-4CWE-602CWE-287

Depth — Manual The comparison is between what the client does and what the server repeats, which requires observing both.

IOS-AUTH-05 Client-Side Authorization Breaches

Objective — Determine whether entitlements are decided by the client, so that modifying it widens what the server will permit.

How it is tested — Identify where the client learns what the user may do — a role in a response, a purchase or subscription state, a feature flag — and whether the client renders that or enforces it. Modify the entitlement data in transit and in the container, and attempt the operations it unlocks. For purchase-gated features, establish whether the receipt is validated by the server or accepted from the device.

Prerequisites — Two accounts at different entitlement levels; a proxy able to modify responses; a device permitting instrumentation and container access.

Indicators — A privileged operation succeeding after modifying client-held entitlement; a purchase state accepted from the device without server validation; entitlement enforced only by what is rendered.

Coverage — MASVS-AUTH-1MASVS-CODE-4CWE-602CWE-285

Depth — Manual Requires modifying client state and confirming the effect against the server.

What we need from you

A device permitting instrumentation of the running application; the decrypted binary; a proxy with interception; two accounts so identity substitution can be tested; and biometric or passcode enrolment where the application uses it.

Standards this category maps to

Every identifier below is quoted from the published control list it belongs to. Where a test has no defensible mapping, none is given rather than an approximate one.

MASVS-AUTH-1 — The app uses secure authentication and authorization protocols and follows the relevant best practices.
MASVS-AUTH-2 — The app performs local authentication securely according to the platform best practices.
CWE-287 — Improper Authentication
CWE-290 — Authentication Bypass by Spoofing
MASVS-PLATFORM-1 — The app uses IPC mechanisms securely.
CWE-939 — Improper Authorization in Handler for Custom URL Scheme
MASVS-AUTH-3 — The app secures sensitive operations with additional authentication.
CWE-603 — Use of Client-Side Authentication
MASVS-CODE-4 — The app validates and sanitizes all untrusted inputs.
CWE-602 — Client-Side Enforcement of Server-Side Security
CWE-285 — Improper Authorization

Tell us what the system does and what worries you.

If a penetration test is not what you need yet, we will say so.

Book a scoping call See the test catalogue