Redirect URI manipulation is an OAuth or OpenID Connect attack in which an attacker alters the redirect URI used in an authorisation request. The goal is to send the response, such as an authorisation code or token, to an endpoint the attacker controls, bypassing the intended callback validation.
What Redirect URI Manipulation Means
redirect uri manipulation is an OAuth and OpenID Connect attack path, so the core security problem is not the redirect itself, but whether the authorisation server sends codes or tokens only to a pre-registered, exact callback location.
When that callback value can be altered, the protocol’s trust boundary shifts from the intended client application to an attacker-controlled endpoint. That can turn a normal login or consent flow into a credential or token capture event.
Why Redirect URI Checks Matter
The redirect URI is one of the few places where the authorisation server hands a response to a client after the user authenticates or consents. If the server accepts weak matching rules, such as partial matches, wildcards, or unsafe normalisation, the response can be diverted without breaking the visible user journey.
This is why exact redirect URI validation is a security control rather than a convenience setting. The issue is closely related to open redirect abuse, especially when a trusted application, browser redirect, or deep-link handler is used as the stepping stone to move the response away from the legitimate client.
For a broader control view of OAuth hardening, OAuth 2.0 Security Best Current Practice Guide is the most direct reference, and it reinforces exact redirect URI matching as part of safer authorisation server behaviour.
Common Attack Paths and Failure Conditions
Redirect URI manipulation often appears alongside registration mistakes, weak client validation, or app-link and deep-link confusion. In practice, attackers look for callback parameters they can tamper with, alternate schemes or hosts that are accepted too broadly, or client implementations that fail to bind the redirect URI to the original authorisation request.
In native or mobile scenarios, the same weakness may be amplified by custom URL schemes, claimed HTTPS links, or handler collisions. In browser-based flows, a vulnerable open redirect on a trusted domain can help move the authorisation response to an attacker-controlled receiver.
Open Redirect Guide is useful here because it covers phishing abuse, OAuth code and token theft, and exact redirect URI matching under RFC 9700.
Mobile Deep Link and App Link Security Guide is equally relevant when the callback is handled by a mobile app, where URI interception and link-handler confusion can create the same end result.
How Organisations Reduce Exposure
Exposure checking starts with inventory: every registered OAuth or OIDC client, every redirect URI, and every place where redirect handling is implemented. Teams should compare what is registered in the authorisation server with what the application actually uses, and they should review vendor guidance when a client library or identity platform performs its own redirect handling.
Where dynamic registration or metadata-based client onboarding exists, the approval path for redirect URIs deserves the same scrutiny as client authentication. The safest posture is narrow allowlisting, stable callback endpoints, and no reliance on user-controlled input to build or select the destination.
OAuth Dynamic Client Registration Security Guide helps when redirect URI governance is affected by how new clients are introduced and controlled.
OAuth Client ID Metadata Documents Guide is relevant when redirect destinations are discovered or supplied through client metadata rather than fixed pre-registration.
OAuth 2.0 and OpenID Connect Guide for Identity Teams provides the broader flow context for roles, grant types, PKCE, tokens, and callback handling.
Detection, Response, and Recovery
Detection is usually about spotting suspicious redirect destinations, unexpected callback domains, mismatched client registrations, or authorisation responses that were issued but not consumed by the legitimate application. Logs from the authorisation server, application telemetry, and web proxy records are all useful because the abuse often happens in a short-lived browser flow.
If exploitation is suspected, response work should include reviewing whether an authorisation code, access token, refresh token, or session artifact was exposed. The priority is to determine what was delivered to the attacker, what can still be replayed, and whether user sessions or downstream API access have to be revoked.
After containment, teams should review the client registration, callback validation logic, and any browser or mobile handoff path that participated in the redirect. The goal is not only to fix the specific bad URI, but to confirm that the application cannot be steered into issuing future responses to an unintended endpoint.
Risk and Threat Considerations
Redirect URI manipulation can expose authorisation codes, tokens, and session-bearing responses to an attacker even when the user completes a legitimate sign-in. The risk is highest when callback validation is loose, because the protocol then trusts a destination the application did not intend.
Failure mechanism: The attacker alters or substitutes the callback value, then receives the OAuth or OIDC response at a location they control, allowing token theft or code interception before the legitimate client can redeem it.
Impact: Depending on the flow and token type, the attacker may gain account access, session hijack capability, or a foothold for broader API abuse and impersonation.
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 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 | Redirect URI handling is a core OAuth/OIDC verification concern. |
| Recommendation — Enforce exact redirect URI validation and bind callbacks to the registered client context. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Codes, tokens, and related secrets exposed through the flow require lifecycle protection. |
| AC-3 — Access Enforcement | Redirect outcomes determine which endpoint receives authorisation artifacts and therefore access. | |
| Recommendation — Rotate or invalidate exposed tokens and review their lifecycle controls after suspected abuse. Restrict callback destinations to approved endpoints and reject unregistered redirects. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Token or code theft from manipulated redirects undermines authentication assurance. |
| Recommendation — Harden the auth flow so a diverted callback cannot be used to obtain valid API access. | ||
Practitioner Guidance
What to watch for: Treat redirect URI registration as a security boundary, not a formatting field. The safest implementations use exact matching, avoid wildcards, and bind the callback to the original client registration and request context.
Governance implication: Identity and application teams should jointly own redirect URI review, because the weakness often sits between application design, identity platform configuration, and mobile or web callback handling. That shared ownership is what prevents drift between what the app expects and what the authorisation server will accept.
Practitioner takeaway: If the redirect can be influenced by user input, pattern matching, or loosely controlled registration, assume the flow is one validation error away from token or code leakage.