Open redirects
An open redirect lets untrusted input choose an unintended navigation destination through a legitimate service.
What it means
An open redirect lets untrusted input choose an unintended navigation destination through a legitimate service. It can support phishing or interfere with authentication workflows that expect tightly controlled callback destinations. Prefer fixed destinations or validated identifiers mapped to approved routes.
A practical example
A login service accepts a return location. It maps a small set of permitted route names to local paths instead of forwarding an arbitrary supplied URL. Authentication callbacks follow their own exact registered destination rules.
What to check
Review redirects after login, logout, payment, and error handling. Validate destinations before navigation and test alternate encodings, scheme-relative URLs, and unexpected hostnames.
A common pitfall
Seeing the legitimate service's hostname at the start of a link does not prove that the eventual destination is trustworthy. The service may immediately forward the browser elsewhere.
Think it through
Why use route identifiers rather than arbitrary return URLs?
Answer: The application can map identifiers to destinations it owns and approves, reducing ambiguity in URL validation.
A trusted first hop can conceal an untrusted second hop
A fictional academy sends learners to their dashboard after login. If a return-location parameter accepts any destination, a link beginning with the academy's domain may lead immediately to another site. The initial hostname can lend credibility to a phishing message even though the final page is unrelated.
Navigation design should distinguish local application routes from external destinations. A route identifier such as dashboard or saved-notes can be mapped to a known path. Where external navigation is a real feature, define the permitted destinations and use one URL parser consistently. String prefixes and substring comparisons are fragile because URL syntax has multiple components and encoded representations.
Authentication flows deserve stricter treatment than ordinary convenience links. Registered callback destinations have a protocol role and should not inherit a broad redirect exception intended for marketing navigation. Likewise, an error handler or logout route can introduce a redirect that bypasses the carefully reviewed login route. Inventory the whole navigation lifecycle.
Review a return-location feature
Create a table for a fictional login service with three intended outcomes: the dashboard, an account settings page, and an explicitly approved partner portal. Explain how the application chooses each outcome without accepting an arbitrary supplied URL. Add an unknown route identifier and state the safe fallback.
When assessing an existing implementation, record the initial URL and final destination using controlled pages. Do not send deceptive links to real users. A strong report explains whether the redirect is simply undesirable navigation or part of a larger authentication or credential-exposure chain. The repair should preserve legitimate workflows while removing ambiguous destination selection, and tests should include both normal returns and prohibited destinations.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Unvalidated Redirects and Forwards