An open redirect is a small flaw with outsized consequences: your app or backend takes a URL from input and sends the user there without checking it, so an attacker crafts a link that looks like it belongs to you but bounces the user to a site they control. In a phishing context that borrows your credibility; in an OAuth flow it can hand an attacker the authorization code or token meant for your app. Mobile apps run into it through OAuth redirect handling and through deep links carrying a return URL. Here is what an open redirect is, where it bites mobile apps, and how to close it.
Short answer
An open redirect is a vulnerability where an app or its backend redirects the user to a URL taken from untrusted input without validating it, so an attacker can craft a link that sends the user to a malicious destination. Per CWE-601, this is used for phishing, borrowing your app's or domain's credibility to send users to an attacker site, and in OAuth flows a loosely validated redirect target can leak the authorization code or token to an attacker. In mobile, it shows up in OAuth redirect handling and in deep links that carry a return URL. The fix is to never redirect to a URL from untrusted input unless it is validated against an allowlist of permitted destinations, and for OAuth to require exact redirect registration and use PKCE.
What you should know
- Open redirect sends users to an input-supplied URL: without validating it.
- It is used for phishing: leveraging your credibility to reach a malicious site.
- In OAuth it can leak codes or tokens: via a loosely validated redirect target.
- Mobile hits it via OAuth and deep links: redirect handling and return URLs.
- The fix is allowlisting destinations: and exact OAuth redirect matching with PKCE.
What is an open redirect?
It is redirecting a user to a destination that untrusted input controls. Many flows legitimately redirect, after login, return the user to where they were; after an action, send them onward, and to do that the code takes a target URL, often from a parameter, and navigates the user there. An open redirect happens when that target comes from untrusted input and is not validated, so an attacker can supply a URL pointing at their own site. The reason it matters is trust transference: the user clicked a link that appeared to belong to your app or domain, so when they end up on the attacker's site, perhaps a convincing copy of your login, they extend the trust they had in you to the attacker, which is what makes open redirects effective for phishing. The flaw is not the redirect itself but redirecting to an unvalidated, attacker-influenced destination, and the fix is to constrain where a redirect may send the user.
Where does it bite mobile apps?
Mainly in OAuth and in deep links. The table summarizes.
| Context | How it arises |
|---|---|
| OAuth redirect target | A loosely validated redirect leaks the code or token |
| Deep link return URL | A link parameter the app navigates to unchecked |
| Backend redirect | The server redirects to a client-supplied URL |
| Phishing via your link | A trusted-looking link bouncing to an attacker site |
| Chained to other attacks | The redirect used as a step in a larger flow |
The highest-stakes mobile case is OAuth: the authorization flow returns to a redirect target, and if that target is not strictly validated, with exact matching of the registered redirect, an attacker can arrange to receive the authorization code or token, taking over the sign-in. This is exactly why OAuth for mobile relies on precisely registered redirects and PKCE, which binds the flow so an intercepted code is not usable. The other common case is deep links: an app that accepts a return URL or next destination as a link parameter and navigates to it without checking can be steered to an attacker URL, sending the user out of the app to a malicious page. A backend that redirects to a client-supplied URL has the same problem. In each, an unvalidated destination is the weakness.
How do you prevent it?
Constrain redirect destinations to ones you trust, and harden OAuth specifically. As a general rule, do not redirect to a URL taken from untrusted input unless you validate it against an allowlist of permitted destinations, your own domains, paths, or schemes, rejecting anything else, rather than trusting whatever URL arrived in a parameter. Prefer not to accept full URLs from input at all where you can avoid it, using an identifier that maps to a known internal destination instead of a free-form target. For OAuth, register your redirect precisely and require exact matching on the authorization server, and use PKCE so that even if a code is intercepted it cannot be exchanged by an attacker, which is the standard for mobile OAuth. For deep links carrying a return or next destination, validate that the destination is within your app or your domains before navigating. Apply the checks wherever the redirect happens, including the backend, since an attacker reaches those directly. The principle is that a redirect may only send the user to a destination you have explicitly allowed, never to an arbitrary URL from input.
What to watch out for
The first trap is a return-URL or next parameter the app or backend redirects to without validation, the textbook open redirect; allowlist the destination. The second is loose OAuth redirect validation, which can leak codes or tokens; require exact matching and use PKCE. The third is assuming an open redirect is low-impact, when it enables convincing phishing and can be chained into account takeover. Redirect and deep-link handling is code you write, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the binary against OWASP MASVS, surfaces your URL handling and authentication configuration as the surface to review, while the destination validation is yours to implement.
What to take away
- An open redirect sends a user to a URL from untrusted input without validation, enabling phishing by borrowing your credibility and, in OAuth, leaking codes or tokens.
- In mobile it appears in OAuth redirect handling and in deep links carrying a return URL, as well as in backend redirects to client-supplied URLs.
- Prevent it by allowlisting redirect destinations, preferring identifiers over free-form URLs, and for OAuth requiring exact redirect matching with PKCE.
- Use a pre-submission scan such as PTKD.com to surface your URL handling and authentication configuration, then validate redirect destinations in your code.
