Scheme Squatting is the registration of a custom URL scheme or intent filter that matches a legitimate app’s link handling before the real app can claim it. Attackers can capture tokens, credentials, or deep-link traffic. Defenders avoid placing secrets in links, prefer stronger app-link mechanisms, and verify target app ownership.
How scheme squatting works
Scheme squatting happens when an attacker registers a custom URL scheme or intent filter that looks like a legitimate app’s handler, then relies on the platform’s app-selection behavior to receive traffic first. The user may believe they are opening the real application, but the link is routed to the attacker-controlled app instead.
This technique is especially effective when applications use deep links to pass users between web and mobile experiences. The routing decision can happen before a human notices the mismatch, which makes scheme names, launch behavior, and app install order part of the security boundary.
Why it is dangerous
The main danger is trust misdirection: the link still appears valid to the user, but the receiving app is not necessarily the intended one. If tokens, credentials, or other sensitive parameters are embedded in the URI, the attacker can capture them and potentially replay them elsewhere.
That exposure is amplified when links carry session material, one-time codes, or account recovery data. Even when the payload is short-lived, interception can be enough to redirect authentication flows, hijack sessions, or reveal information that should never leave the original app boundary.
Where organizations get exposed
Exposure usually starts with mobile apps that define custom schemes, weak deep-link validation, or ambiguous ownership of link handlers. The risk is not limited to one platform, because the same basic pattern appears whenever the operating system must choose between multiple apps that claim the same or similar route.
A practical way to assess exposure is to inventory every place your product emits a URI that can be opened by an app, then verify whether those links can be claimed by another installed application. NHI Management Group’s Mobile App Security Guide is a useful reference for deep links, intent spoofing, and related mobile app attack paths.
For app teams, the security question is whether the target app is strongly verified or merely assumed. Stronger app-link mechanisms reduce ambiguity, while custom schemes need careful ownership checks and stricter handling of any data carried in the link.
Safer design and response patterns
The best design choice is to avoid putting secrets in links at all, because any handler confusion turns the link into a disclosure channel. Where link-based handoff is unavoidable, prefer mechanisms that verify app ownership rather than relying on the first registered scheme handler.
After a suspected exposure, treat the link as compromised input and rotate anything it may have exposed, including tokens, credentials, and session artifacts. Review logs for unusual redirects, unexpected app launches, or repeated link opens that do not match normal user behavior.
Mobile security controls that harden storage and authentication are part of the broader defense picture, but they do not fix scheme squatting by themselves. The underlying issue is link routing trust, so the response must focus on link design, handler validation, and post-exposure credential hygiene.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V10 — OAuth and OIDC | Scheme squatting can hijack OAuth handoffs that rely on app redirects. |
| Recommendation — Use verified redirect and handoff flows that do not expose tokens to untrusted app handlers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Captured links can expose credentials, tokens, and session material that require lifecycle control. |
| Recommendation — Rotate any exposed authenticators, tokens, or secrets after suspected interception. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen deep-link tokens can undermine authentication flows and session integrity. |
| Recommendation — Treat intercepted link material as compromised authentication data and invalidate it promptly. | ||
| CIS Controls v8 | CIS-5 — Account Management | Compromised link-based credentials may require account and token review across affected identities. |
| Recommendation — Review and remove exposed accounts, tokens, and stale access paths after a squatting incident. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | Handlers should not receive sensitive link traffic without verified access and ownership controls. |
| Recommendation — Enforce verified access paths so only the intended app can receive sensitive link traffic. | ||
Related resources from NHI Mgmt Group
- How should scheme operators govern OpenID for Verifiable Credentials implementations?
- What should organisations change after a large-scale labour fraud scheme?
- Why do squatting and dependency confusion matter for IAM teams?
- What breaks when software supply chain controls do not account for AI-driven package squatting and fake contributor activity?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org