Deep link hijacking
Deep link hijacking is the interception of a link intended for one mobile application by another application that has registered the same handler. Where the link carries an authorisation code or a token, the interceptor receives it, which is how an account is taken over on a device without any flaw in the server.
The weakness is in the older style of link, where an application claims a custom scheme by declaring it. Nothing prevents a second application from declaring the same one, and the resolution when both are installed is not something the legitimate application can control. Verified links, which bind an application to a domain the developer proves control of by publishing a file on that domain, remove the ambiguity, and they are the only form that should carry anything sensitive.
The chain that matters is OAuth 2.0 on mobile. If the authorisation code is returned to a custom scheme, a malicious application that registered the same scheme receives the code and exchanges it for tokens. The defence is PKCE, defined in RFC 7636, which binds the code to a secret the requesting application generated, so a stolen code cannot be exchanged by anyone else. It is required practice for native applications and it is still missing from integrations we test.
Enumerating handlers is quick: the declared schemes and domains are in the application manifest, and testing which ones accept parameters from another application is a matter of sending them. What we look for is any handler that performs an action or accepts a credential without further checks, and the finding is written as account takeover where the chain completes. This is a standing item in the mobile testing where every registered link handler is enumerated.