URI Hijacking is the abuse of a registered or intercepted uniform resource identifier scheme so a malicious app opens links meant for another application. Attackers use it to steal tokens, redirect login flows, or capture sensitive data. Defenders audit link handlers, app associations, and unexpected redirects.
What URI hijacking actually exploits
URI hijacking abuses how operating systems route a link or custom scheme to an application. When the wrong app is registered, installed later, or allowed to intercept a scheme, a user action meant for one app can be silently diverted to another.
This matters because the redirect point is often treated as trusted plumbing, not as a security boundary. If an attacker can win that routing decision, they can impersonate the intended app at the moment a token, code, or sensitive payload is handed off.
Why URI hijacking is dangerous
The core danger is trust confusion during link handling. A malicious app can receive login callbacks, authorization codes, deep-link parameters, or other sensitive data that the user expected to go to a legitimate application.
That can expose session material, facilitate account takeover, or let an attacker alter the user journey at the exact point where the application assumes a safe return path. In mobile ecosystems, this is especially risky because scheme registration, app associations, and custom handlers are often fragmented across platform features and third-party apps.
How organisations should assess exposure
Exposure review starts with knowing which applications register custom schemes, universal links, or deep links and which flows depend on them. Teams should inventory mobile apps, login callbacks, and any redirect path that passes secrets or authentication artefacts.
It is also important to test the full environment, not just a single app build. Scheme collisions, unexpected redirect destinations, and link-handler ambiguity often appear only when multiple apps are installed or when a new app claims a previously unused scheme.
For a broader view of mobile attack surface and link-handling pitfalls, the Mobile App Security Guide covers deep links, intent hijacking, webview exposure, and related mobile controls.
Remediation and detection priorities
Defences should reduce what the redirect can carry and make interception easier to spot. Use hardened redirect handling, prefer standards-based app linking where possible, avoid placing long-lived secrets in URLs, and design flows so that a diverted callback does not immediately grant access.
Detection should focus on unusual redirect destinations, unexpected app associations, and post-login behaviour that does not match the intended client. After a suspected hijack, review whether tokens, codes, or sessions were exposed and revoke or rotate the affected material where necessary.
Mobile application teams can map these risks against the Mobile App Security Guide because the same deep-link and intent-handling failures often create the compromise path.
Risk and Threat Considerations
URI hijacking creates a high-value interception point because attackers do not need to break the primary app, they only need to win the routing decision for a trusted link or callback. That makes it attractive for stealing authorization data, redirecting authentication flows, or capturing sensitive parameters before the legitimate app can process them.
Failure mechanism: A malicious or conflicting app registers the same scheme, intercepts the link, and receives data that was assumed to be delivered to the intended application.
Impact: The result can be token theft, login-flow hijack, user impersonation, or exposure of sensitive application data during redirects.
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 | URI hijacking often targets OAuth redirect and callback handling. |
| Recommendation — Validate redirect URI handling and avoid exposing authorization codes to alternate handlers. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Hijacked links can expose tokens and other authenticator material during app redirects. |
| Recommendation — Protect, rotate, and revoke exposed tokens or secrets after suspected interception. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen callback tokens or codes can undermine authentication across app and API flows. |
| Recommendation — Harden authentication flows so intercepted callback data cannot be reused for access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Link hijacking can lead to account compromise and unauthorized session use. |
| Recommendation — Review and remove compromised access paths after suspected URI hijacking. | ||
| NIST CSF 2.0 | PR.AA-01 — Identities and credentials are managed for authorized users, software, and devices | URI hijacking affects how software identities and credentials are handled in client flows. |
| Recommendation — Manage application trust paths so only intended software can receive sensitive redirects. | ||
Practitioner Guidance
What to watch for: Treat custom schemes and redirect handlers as security-sensitive interfaces, not convenience features. The biggest mistake is assuming a link will always resolve to the intended app just because it worked in testing.
Governance implication: Application owners should document which flows depend on URI routing, own the redirect design, and review them when apps, SDKs, or mobile platforms change. If a flow can be abused by a competing handler, redesign it before relying on it for sensitive transactions.