Your SSO login callback has an open redirect (it will redirect to any URL passed in a parameter). What's the risk?
Short answer
An open redirect on an auth flow lets an attacker craft a trusted-looking login link that, after authentication, sends the user — and potentially an auth code or token — to an attacker-controlled domain, enabling account takeover and convincing phishing. Fix it by strictly allow-listing exact redirect URIs server-side and rejecting anything else. It is not cosmetic and not a performance issue, and HTTPS doesn't help because the attacker's destination can be a valid HTTPS site too.
An open redirect is often dismissed as low severity — until it sits on an authentication callback. There, it stops being a phishing nuisance and becomes a route to account takeover, because the thing being redirected can carry credentials, an authorization code, or a token.
Why this is high risk
In an SSO/OAuth flow, the user authenticates and the provider sends them back to your callback, which then forwards them onward. If that forward target is attacker-controlled (because the redirect parameter isn't validated), two bad things happen:
- Phishing with a real, trusted domain. The malicious link starts at your legitimate login URL, so it passes the user's "is this the real site?" check, then bounces them to the attacker's page to harvest credentials or consent.
- Token/code theft. If the authorization code or token rides through the redirect (in the URL or via Referer/fragment leakage), the attacker's domain receives it and can exchange or replay it to take over the account.
The correct fix
Strictly allow-list redirect URIs server-side, comparing against an exact, pre-registered set of values — not a prefix, substring, or "same domain" check, all of which attackers bypass (https://yoursite.com.evil.com, //evil.com, path tricks). Reject anything not on the list. Combine this with the OAuth state parameter (CSRF protection) and PKCE to harden the flow end to end.
Why the distractors are wrong
- "Purely cosmetic" and "slightly slower logins" badly misjudge severity — the bug can leak the very token that is the user's session.
- "No risk as long as the site uses HTTPS" misunderstands the threat: HTTPS protects the connection, but the attacker simply hosts their landing page on their own valid HTTPS site. Transport encryption does nothing to stop a redirect to a malicious destination.
The interviewer is probing whether you recognize that an open redirect on an auth path is a credential-theft primitive, and whether you reach for exact-match allow-listing rather than a clever-but-bypassable filter.
Likely follow-ups
- How does an open redirect on an OAuth redirect_uri turn into authorization-code theft?
- Why is exact-match allow-listing safer than prefix or domain matching?
- What role do the state parameter and PKCE play alongside redirect_uri validation?