Authentication Flaws Testing

Mobile authentication testing examines what the application accepts as proof of identity and where that proof is evaluated. The recurring failure is a decision taken on the device — which the device's owner controls — that the server then treats as settled.

What an attacker is trying to achieve

The attacker controls the device completely. Any check that runs there can be removed, and any value the device asserts can be forged. They want the server to accept an identity the device merely claimed, or to reach the application's protected state by defeating a local check.

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.

AND-AUTH-01 Insecure Authentication Vectors

Objective — Determine whether identity is established from device-derived values — hardware and network identifiers, installation identifiers — which the device's owner can change or forge.

How it is tested — Identify every value the client sends that contributes to identifying the user or the installation. Establish which are device-derived and whether the server treats any as authenticating rather than merely describing. Substitute another installation's values, and values belonging to a different account, and observe whether the server accepts them. Test whether such a value alone grants access without a credential.

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

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 distinguish descriptive from authenticating.

AND-AUTH-02 Cross-Application Authentication

Objective — Determine whether authentication shared between the vendor's applications, or delegated to another application on the device, can be abused by an application that should not participate.

How it is tested — Identify how authentication state is shared: a shared account, a shared storage location, a component invoked across applications, or a token passed by message. Establish what verifies the caller in each case, and attempt to obtain or use that state from an unprivileged test application. For delegated sign-in, establish whether the returning response is bound to the request that started it.

Prerequisites — A device; the vendor's related applications where they exist; a test application; the decompiled package to locate the sharing mechanism.

Indicators — Authentication state readable or usable by an unprivileged application; a shared component granting a session without verifying the caller; a delegated response accepted without binding to its request.

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

Depth — Manual Requires a second application acting as the untrusted participant.

AND-AUTH-03 Local Authentication Bypass

Objective — Determine whether an on-device authentication step — biometric, PIN or pattern — can be bypassed, and whether anything of value depends on it having succeeded.

How it is tested — Establish what the local check protects and whether the protected material is cryptographically bound to it or merely gated by it. Instrument the running application to force the success path without performing the authentication, and observe whether the protected function proceeds. Establish whether the server is involved at all, and whether the local result is asserted to it as a claim the server trusts.

Prerequisites — A device permitting instrumentation of the running application; the decompiled package; a proxy to observe what the server is told.

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

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

Depth — Manual Confirmation requires instrumenting the running application, not reading its code.

AND-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 — Trace the authentication exchange and identify what the client computes and what the server verifies. Modify client-side outcomes — success flags, validation results, derived values — in transit and by instrumentation, and observe whether the server notices. Establish whether credential validation, attempt counting or second-factor verification occurs on the device, and whether the resulting session is fully privileged.

Prerequisites — A proxy with interception; a device permitting instrumentation; the decompiled package; an account whose sign-in can be repeated freely.

Indicators — A client-computed result accepted without verification; attempt counting enforced only on the device; a session granted on a client-asserted outcome; validation logic present in the client and absent from the server.

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.

AND-AUTH-05 Client-Side Authorization Breaches

Objective — Determine whether what a user may do is decided by the client, so that modifying the client widens what the server will permit.

How it is tested — Identify where the client learns the user's entitlements — a role in a response, a feature flag, a menu the server populates — and whether the client merely renders that or enforces it. Modify the entitlement data in transit and on the device, and attempt the operations it unlocks. Establish whether the server re-checks entitlement on each operation or trusts that the client would not have offered it.

Prerequisites — Two accounts at different privilege; a proxy able to modify responses; a device permitting instrumentation.

Indicators — A privileged operation succeeding after modifying client-held entitlement; the server accepting an operation the interface would not have offered; entitlement enforced only by what is rendered.

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

Depth — Manual Requires modifying client state and then confirming against the server, which is two halves of one test.

What we need from you

A device or emulator with elevated privileges and the ability to instrument a running application; the decompiled package; a proxy with interception; and at least two accounts so identity substitution can be tested rather than inferred.

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-926 — Improper Export of Android Application Components
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