Review trust boundaries in mobile and native clients

A mobile or desktop client runs in an environment the application does not fully control. A person can inspect stored files, alter requests, invoke exported components or replace application code. That does not mean every device is compromised; it means server authorization cannot rely on a hidden button, an obfuscated string or a client-computed isAdmin flag. Treat the client as a presenter of credentials and requested actions. The server determines the caller's current permissions.

Follow a concrete expense application. Alice belongs to tenant red and can view her own report R8. The app stores a session credential and displays R8. A deep link expense://report?id=R9 opens a report screen. If the server checks only a valid session, changing R8 to another person's R9 exposes the report regardless of the app's local validation. Device integrity signals may influence a risk decision, but they cannot establish Alice owns R9. The permission check belongs at the API's resource boundary; /domains/appsec/authorization/object-level-authorization/ shows it in code.

Draw the credential's path from login to refresh, secure platform storage, memory, network use, logs, backup and logout. Platform credential facilities can reduce exposure compared with ordinary preferences, but their protection depends on access settings, device state and threat model. A token in secure storage is still available to the app when legitimately used; it does not authorize arbitrary server actions. Avoid placing credentials in URLs, analytics, crash reports or exported files.

Next enumerate entry points that bypass the normal interface: app links, custom URI schemes, share targets, exported activities, webviews, local IPC and privileged helpers. A link is untrusted input even when it looks like your product's URL. Parse it structurally, accept a small operation vocabulary and let the destination screen load only through authenticated, authorized APIs. Opening a review screen is a safer link action than immediately approving a payment or replacing an account credential. For webviews, keep untrusted navigation separate from native bridges and authenticated application content.

The Swift function below is a strict parser for the expense app's only link. It accepts exactly expense://report?id=R<digits> and returns nothing for an extra parameter, a duplicated id, a different host such as approve, a path, user info, a port, a fragment or a different scheme, so a link can open a review screen but never trigger an action. It deliberately accepts R9: whether Alice may see that report is the server's decision, not the parser's. The file compiles against the iOS 27 SDK, and with 11 test cases in a main.swift it runs on macOS with swiftc. Android and iOS configuration for the same boundaries, such as exported components, verified links and keychain classes, is in /domains/appsec/platform-security/android-ios-security/.

import Foundation

enum LinkAction: Equatable {
    case viewReport(id: String)
}

/// Accepts exactly expense://report?id=R<1-9 digits>. Anything else opens nothing.
/// The report screen still loads the id through the authenticated, authorized API.
func parseLink(_ url: URL) -> LinkAction? {
    guard let parts = URLComponents(url: url, resolvingAgainstBaseURL: false),
          parts.scheme == "expense", parts.host == "report",
          parts.user == nil, parts.password == nil, parts.port == nil,
          parts.path.isEmpty, parts.fragment == nil,
          let items = parts.queryItems, items.count == 1,
          items[0].name == "id", let id = items[0].value,
          id.range(of: #"^R[0-9]{1,9}$"#, options: .regularExpression) != nil
    else { return nil }
    return .viewReport(id: id)
}

A useful test changes only one trust assumption. Alter a report id while preserving Alice's valid session: the server must deny the foreign report. Remove the session while keeping a legitimate deep link: the app may show login, but must not show report data. Forge a premium=true local flag: the server must still enforce purchase entitlement. After logout, verify the refresh credential is revoked according to policy and sensitive local cached reports are cleared or inaccessible to the next account.

Use synthetic records and inspect both client-visible state and server response. A screen that hides an error while a background API response contains the foreign report still fails. Conversely, a denied API call does not prove a previously cached screen stopped displaying private information. Device snapshots, backup restoration and account switching are especially useful boundary cases because they reintroduce data after the normal happy path has finished.

The iOS and Android projects on /labs/ run the same link contract through the platforms' own parsers, URLComponents and android.net.Uri: look-alike hosts, user info, extra parameters and encoded separators open nothing, a valid link only opens a review screen, and payment needs the user's tap there.

Offline features create an explicit period during which the device cannot learn about server-side revocation. Decide whether an offline report is permitted, what fields it includes and when the local copy expires. Do not promise immediate revocation for data already delivered and stored on an offline device. Minimize retained data and require fresh server authorization before new high-impact operations when connectivity returns.

Obfuscation, root or jailbreak checks, attestation and anti-debugging may raise the cost of tampering. They add support and availability tradeoffs and can produce false denials on legitimate devices. Document the response to an unavailable attestation service rather than allowing a network error to grant extra authority. A practical review gives each control its job: secure storage limits credential exposure, transport validation protects the connection, server policy controls resources, and narrow entry points constrain what outside content can ask the client to do. Keep the platform's TLS certificate validation enabled, and test that the app fails safely on an invalid or intercepted certificate rather than disabling checks to make a request succeed. Certificate pinning, MASVS-NETWORK-2, adds rotation and recovery obligations of its own.

These controls map onto OWASP MASVS v2.1.0: MASVS-STORAGE-1 and MASVS-STORAGE-2 for local copies, MASVS-PLATFORM-1 and MASVS-PLATFORM-2 for links, IPC and WebViews, MASVS-NETWORK-1 for transport, MASVS-AUTH-1 for the server-side decisions and MASVS-RESILIENCE-1 to MASVS-RESILIENCE-4 for tamper resistance. In the OWASP Mobile Top 10 2024 they correspond mainly to M1 Improper Credential Usage, M3 Insecure Authentication/Authorization and M9 Insecure Data Storage.

CVE-2017-13156 (Janus) let an attacker modify an Android APK's code without breaking its signature, because the v1 signature scheme ignored bytes prepended to the file. The missing control was verifying integrity with APK Signature Scheme v2 or later.

Three scenarios require different controls. First, an attacker copies a refresh credential from a log: storage hygiene, restricted diagnostics, revocation and credential lifetime limit that exposure. Second, Alice modifies her own client to request Bob's report: only the server's resource authorization prevents that request from succeeding. Third, Alice legitimately downloads her own report and later loses membership while offline: the server cannot retroactively un-deliver those bytes. A review that labels all three 'device security' can choose an expensive control that addresses none of the actual missing boundaries.

For a high-impact operation such as expense reimbursement, keep the decision online and bind approval to the displayed transaction details. The client can submit report id and intended amount, but the server reloads the current approved report and checks the actor's authority. A locally cached approval from yesterday should not approve an edited report today. If the server issues a short-lived authorization challenge, bind it to the relevant report revision and operation rather than a generic 'user passed authentication' flag.

Verification can stay precise without using a compromised production device. Supply the normal API request, change only report id or revision, and inspect the synthetic server state. Then test the separate local lifecycle with account switch and restored cache. This division lets the team identify whether a failure belongs to server policy, credential handling or local privacy rather than treating every visible symptom as an anti-tampering problem.

Sources & further reading

The standards, specifications and documentation behind the guidance above. Each is the evidence for a claim on this page; consult it for detail beyond the defaults and versions listed here.

1. OWASP Mobile Application Security Verification Standard
2. Android Developers: security best practices
3. OWASP MASVS v2.1.0 release
4. OWASP Mobile Top 10 2024
5. Apple: URLComponents
6. NVD: CVE-2017-13156, Android Janus APK signature bypass

Reference information

Tags

Mobile appsDesktop and native appsThreat modeling

SDLC phase

DesignDevelopment

Role

DevelopersAppSec engineers

ASVS 5.0.0 requirements

v5.0.0-8.3.1 · v5.0.0-2.2.2

Download this guide as Markdown

Continue exploring