Mobile App Security: Tokens, Deep Links, and API Trust

Short answer

The key mobile security question is not whether an app package is secret. It is what the backend still authorizes when an attacker controls the device and client. Review token storage, incoming deep links, WebViews, and device signals, then prove that every sensitive decision is revalidated on the server.

This guide focuses on three boundaries instead of repeating a general mobile pentest scope: credentials on the device, links entering the app, and authority carried from the client to APIs. Failures can enable account takeover or transaction abuse in banking, fintech, commerce, and enterprise apps.

Where are tokens stored?

Identify where access and refresh tokens live and what controls protect them. Android Keystore or iOS Keychain is not the end of the review. Check backups, debug logs, crash reports, clipboard, screenshots, and third-party SDKs. Encryption does not help if the key can be extracted as easily as the app.

On a controlled test device, inspect app files, backups, logs, IPC, and runtime behavior. Do not treat root or jailbreak detection as an absolute control. Establish which token is exposed under which conditions and what server-side authority it provides.

Trace tokens after logout, password change, MFA reset, device removal, and account suspension. Logout that deletes only local storage may leave a copied refresh token active. Confirm that the backend checks current session state before sensitive operations.

Deep links carry untrusted input

Multiple apps can register a custom URL scheme. If a callback or sensitive action relies on one, test whether another app can claim the same scheme. Android App Links and iOS Universal Links establish verified domain associations, but do not remove the need to validate parameters.

Treat redirect, next, account, code, order IDs, and campaign values as untrusted. Opening a link should not complete a transfer, password change, or MFA removal. Sensitive actions require server authorization and user confirmation.

Test	Expected result
Another app registers the same scheme	No session or authority leaks
Link contains an external redirect	Destination stays within an allowlist
Link references another user’s object	Backend denies access
Link token is expired or reused	Expiry and single-use checks apply
Callback arrives after app restart	State and code still match the session

A login callback’s state and, where appropriate, PKCE must bind the same transaction even after the app closes and reopens. Errors must not leave tokens in URLs, analytics events, or user-visible messages.

Client checks are not backend authorization

Hiding a button, closing a role-specific screen, or showing a biometric prompt does not authorize an API request. The server must verify identity, object ownership, tenant membership, and current business rules. Using a safe test account, show that an API rejects the request after client checks are bypassed.

Device fingerprint, root status, or app-integrity signals can inform risk decisions; they should not become the only permanent proof of authority. If a signal service is unavailable, require additional verification or restrict sensitive actions. Do not fail open.

Test sequence

Identify supported Android/iOS versions and login, payment, and recovery flows.
Review token storage, backups, logs, and logout with a test account.
Exercise deep links with malformed, expired, reused, and cross-account values.
Bypass client checks and verify the server denies the API request.
Assess biometrics, device changes, root signals, network failure, and app restart.
Report version, device, role, affected action, and retest criteria.

Place device signals and user confirmation correctly

Biometrics often unlock a key stored on the device; they do not replace the backend’s identity and transaction checks. For transfers, adding a payee, or changing security settings, test whether biometric failure falls back to a weaker path. Session restoration, a deep link received on another device, and an action launched from a notification should all enforce the same business rules.

Notifications should not contain sensitive data or a link token that grants authority by itself. Include lock-screen previews, app-switcher snapshots, and screen sharing in the review. If the app restricts screenshots on a sensitive screen, check consistent platform behavior and accessibility impact; this control still does not replace server authorization.

Make findings reproducible

A report should identify the app and OS versions, device state, test role, starting session, and affected API or action. Redact tokens and use synthetic accounts where possible. Retest the same flow after remediation and add a negative control: normal links, login, and authorized actions should continue to work while the attacker-controlled variant is denied.

Rate a deep-link finding by the action it enables in a particular user context, not by the fact that a link opens. A route that opens a harmless screen is different from an authentication callback that transfers a session to another app.

Review mobile and API ownership controls together with our mobile application security service.