Security teams detect Scheme Squatting by checking whether a custom URL scheme or deep link can be registered by an untrusted app before the legitimate one. Review scheme ownership across installed apps, test link resolution on target devices, and confirm that sensitive links use strong app links or other verified routing.
How Scheme Squatting Works in Practice
Scheme squatting is a mobile and deep-link routing problem, not just a generic app bug. The weak point is the trust a device places in a URL scheme or deep link handler. If an untrusted app can claim the same scheme first, it may intercept links intended for the legitimate app and expose tokens, session data, or navigation into attacker-controlled flows.
Detection starts by treating scheme ownership as something you can test, not assume. Review the apps installed on representative devices, then validate which app actually resolves each custom scheme or deep link. A security team should compare declared handlers with observed resolution behaviour, because the effective handler on the device is what matters.
Strong detection also looks for routing paths that are too permissive. Where a sensitive action depends on a custom scheme alone, the safer pattern is verified app links or equivalent OS-backed routing that reduces ambiguity. The Mobile App Security Guide covers related mobile testing areas such as deep link hijacking, intent interception, and mobile app vetting.
What to Check to Confirm Exposure
Confirm exposure by testing the exact user journeys that matter, not only the presence of a scheme registration. Use a device matrix that reflects the platforms and build variants you support, then open the links from the contexts attackers would realistically abuse, such as browsers, email, chat, and embedded web views. If the wrong app opens, or the link can be captured by an untrusted package, you have a real detection finding.
It is also important to review whether the link carries sensitive material before the app is fully trusted. If the scheme is used to return authentication data, one-time codes, or state parameters, the routing control becomes part of the security boundary. In that case, the test is not only “does it open”, but “can a malicious app observe or influence what is returned”.
For teams that need a repeatable method, combine manual testing with mobile security verification and device configuration review. That helps distinguish a vulnerable routing design from a one-off installation anomaly, and it makes the finding actionable for engineering.
How to Reduce False Negatives in Testing
A common miss is testing only the happy path on a clean lab device. Scheme squatting often depends on which apps are present, installation order, and how the operating system resolves competing handlers. Good detection therefore includes testing with untrusted or non-business apps installed, then re-checking after updates, app reinstalls, and OS upgrades.
Security teams should also look beyond custom schemes where possible. Sensitive flows should move to verified app links, strong redirect validation, or other OS-supported mechanisms that bind the destination more tightly than a plain scheme name. That reduces the chance that a malicious or unrelated app can hijack the link path.
When a team documents the issue, the finding should name the exact scheme, the affected route, the observed handler, and the impact of interception. That level of detail makes it easier for mobile engineers to decide whether to redesign the flow, change the link type, or add compensating validation in the receiving app.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Deep link flows often carry auth redirects and state, so verified routing supports secure token return. |
| Recommendation — Require verified redirect handling and reject untrusted deep-link return paths. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Scheme hijacking can expose tokens or codes, making credential handling and rotation relevant. |
| Recommendation — Protect and rotate any credentials or secrets exposed through intercepted link flows. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Scheme squatting can expose tokens or secret-bearing link parameters through intercepted routing. |
| NHI-10 — Human Use of NHI | User-triggered deep links can be abused when humans launch sensitive flows through untrusted handlers. | |
| Recommendation — Eliminate secret-bearing data from links that can be intercepted by an untrusted app. Move sensitive actions away from link handlers that depend on user-triggered app selection. | ||
Practitioner Guidance
What to verify: Test the same scheme on multiple target devices and OS versions, because handler resolution can vary with install order, default associations, and platform behaviour. A single clean-device test is not enough to prove resilience.
What good looks like: Sensitive deep links use verified routing, the intended app is the only valid receiver, and no untrusted package can claim the same path without failing validation. If the link cannot be made exclusive, treat the flow as high risk and redesign it.
Common mistake: Teams often assume that a unique-looking custom scheme is safe because it is obscure. Obscurity does not prevent squatting, and it does not stop another app from registering the same handler if the platform allows it.
Practitioner takeaway: Treat scheme squatting as a routing integrity issue, not a cosmetic mobile flaw. The most reliable defence is to verify actual handler behaviour on real devices and eliminate sensitive dependence on unverified custom schemes wherever possible.