What changed when mobile security stopped being theoretical

What it is

An opinion piece by the Head of Engineering at Oversecured, a mobile security vendor, who has built for the web since 2002. Based on patterns seen in real production apps, the author argues that familiar mobile risks are more frequent and more combinable than most teams assume. The page names no CVEs, tools or figures. Its specifics are the mechanisms and mitigations below.

How it works

Three mechanisms go beyond the catalog summary.

• Storage is one link in a chain. A token can sit correctly in the Keychain or Keystore and still leak through a log, an analytics event, the clipboard or an unencrypted cache file. The page says this pattern ("a token in the vault and a copy in the logs") keeps turning up in real apps.
• Storage configuration changes the guarantee. A migratable Keychain accessibility class lets data carry over through backup and restore, which defeats single-device binding. "Stored in Android Keystore" does not by itself mean secure hardware backs the key, because hardware backing varies by device and configuration.
• Custom URL schemes can be hijacked. Another app can register the same yourapp:// scheme and receive links meant for yours. If those links carry a magic-link token or an OAuth redirect, a malicious app can intercept them. Deep-link handlers and exported intent receivers can also be invoked directly with arbitrary parameters. A recurring finding is a link that jumps into a flow assuming the user already passed two earlier screens and their checks.

flowchart LR
    A[Malicious app or webpage] -->|crafted link| B{Link type}
    B -->|Custom scheme| C[Any app can claim it]
    B -->|Verified App Link / Universal Link| D[Delivered to your app only]
    C --> E[Token or OAuth redirect intercepted]
    D --> F[Handler still callable with any parameters]

What to do

• Use verified App Links (Android) and Universal Links (iOS) for anything carrying sensitive values. The page calls them part of the security model.
• Check the Keychain accessibility class against whether the data may migrate. Do not infer hardware backing from the Keystore API name.
• Trace each sensitive token past storage: logs, analytics, clipboard and cache files.
• Treat deep links, exported activities, services and intent receivers as public endpoints. Re-check at the handler any state the normal screen flow would have established.
• Plan containment for old binaries before release: revoke credentials, disable endpoints, enforce a minimum version, and request expedited review.
• Test the artifact that ships, not only the source.

Caveats

The page says containment measures are damage control and not equivalent to a deploy. Old builds cannot be reliably replaced or erased. It says obfuscation slows extraction of embedded secrets but does not change the outcome. It gives no frequency data, example apps or step-by-step tests, so the claim that these issues are common rests on the author's account.