Open redirect phishing is phishing that abuses a legitimate site’s redirect function to send users to a malicious destination. The trusted domain in the first link helps bypass user suspicion and some filters. Defenders should audit redirect parameters, restrict unsafe redirects, and review email and web filters for redirected URLs.
How open redirect phishing works
open redirect phishing turns a legitimate redirect feature into a trust bridge. A user clicks a link on a real domain, the browser follows a redirect parameter, and the final destination becomes a malicious site that looks less suspicious because the first hop was trusted.
This technique is effective because users, email gateways, and sometimes browser tooling often give a trusted domain more credibility than the final landing page. It is especially useful when the attacker wants to disguise a credential prompt, a malware download, or a fake sign-in page behind a reputable brand or service.
Why open redirects are attractive to attackers
Open redirects do not usually create the final malicious content, but they help deliver it. That makes them valuable for phishing kits, brand impersonation, and link laundering, because the attacker can borrow legitimacy from a safe domain while still steering the victim elsewhere. NHIMG’s Phishing Guide covers open redirect phishing as part of broader phishing tradecraft and defences.
The same pattern can also help bypass simplistic reputation checks that rely on the first URL or a trusted domain prefix. Once the victim reaches the redirect chain, the real risk is the same as ordinary phishing: credential theft, session theft, or malicious code execution after the user trusts the page enough to interact with it.
How organisations check and reduce exposure
Exposure usually sits in web application design, email filtering, and URL handling. Organisations should inventory applications that accept destination parameters, review whether those parameters permit arbitrary external targets, and confirm that mail and web controls inspect the final destination rather than only the first hop. A redirect feature is often legitimate, but it should be constrained so it cannot become a generic off-domain forwarding service.
For implementation guidance, the most effective review starts with the application itself. NHIMG’s Web Application Attacks Guide places open redirect alongside other redirect and forwarding weaknesses that defenders should test during secure design and verification. OWASP API Security Top 10 is also useful when redirect logic is exposed through APIs, because weak object or function authorization can make redirect behavior easier to abuse at scale.
Where redirect destinations must remain dynamic, defenders should prefer allowlists, tight domain matching, and explicit user-visible destination handling over free-form URL parameters. The operational goal is not to remove all redirects, but to ensure that only intended navigation paths are possible.
Detection, response, and post-click review
Detection should look beyond the initial link and trace the full chain. Security teams can inspect web logs for unusual redirect parameters, repeated short-link usage, high volumes of off-domain forwarding, and email events where a trusted domain immediately resolves to a different host. If a campaign is active, defenders should also search for landing pages that reuse a trusted brand while changing the final domain only after the redirect occurs.
After a suspected click, the review should focus on what the victim exposed at the destination. If credentials, tokens, or session cookies were entered, those should be treated as potentially compromised. Where the redirect was used to deliver a fake login, the incident response priority is usually account reset, session invalidation, and verification that no attacker-controlled forwarding path remains in the user journey.
NHIMG’s Dropbox GitHub breach 2022 and Mailchimp breach 2022 are useful reminders that phishing often becomes a broader compromise when the attacker reaches staff tools, keys, or export capabilities rather than stopping at the inbox.
Defensive patterns that make redirects safer
The safest pattern is to keep redirects boring and predictable. Use explicit allowlists for approved destinations, remove or constrain any parameter that accepts raw external URLs, and separate user convenience redirects from security-sensitive flows such as sign-in, password reset, or consent. When a redirect is unavoidable, log it, validate it, and make the destination visible to the user before any sensitive action occurs.
Defenders should also align browser, email, and web protections so they evaluate the final URL, not just the first one. That matters because open redirect phishing succeeds by exploiting the gap between a trusted origin and an untrusted destination. NHIMG’s Phishing Guide provides a broader control set for layered phishing defence, while NIST SP 800-63 Digital Identity Guidelines reinforces why phishing-resistant authentication is the right long-term answer when users are being pushed toward fake sign-in pages.
Risk and Threat Considerations
Open redirect phishing increases trust abuse, because a legitimate domain is used as a transit point to a malicious destination. That can reduce user suspicion, weaken URL-based filtering, and make the attack look like a normal click until the final page is already loaded.
Failure mechanism: The redirect function accepts or forwards an untrusted destination, then the attacker chains it into a phishing lure that appears to start on a legitimate site.
Impact: Victims may disclose credentials or sessions, and defenders may miss the attack if they only review the first URL or the nominally trusted origin.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Open redirects are a web-service input validation and request-handling issue. |
| V15 — Secure Coding and Architecture | Redirect logic is an application-design weakness when unsafe forwarding is possible. | |
| Recommendation — Validate redirect targets and reject unsafe destination parameters in web and API endpoints. Design redirect flows so untrusted input cannot control off-domain navigation. | ||
| NIST SP 800-53 Rev 5 | SC-23 — Session Authenticity | Phishing via redirects can exploit trust in URLs and sessions around authentication flows. |
| SI-10 — Information Input Validation | Unsafe redirect parameters are untrusted input that must be validated before use. | |
| Recommendation — Protect authentication and session workflows from deceptive redirect-based abuse. Validate and constrain redirect parameters before they are processed. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application security controls should address unsafe redirect and forwarding behavior. |
| Recommendation — Review application logic for open redirects and remove unsafe forwarding paths. | ||
Practitioner Guidance
What to watch for: Treat any application that accepts a return, next, redirect, or continue parameter as a candidate for abuse, especially if it is reachable from email, login, password reset, or consent flows. Redirect features should be reviewed as security-relevant input handling, not just as convenience logic.
Governance implication: Assign ownership for redirect validation, logging, and filter testing so application teams, email security, and identity teams do not each assume another control layer will catch the abuse. Where user authentication is involved, favour phishing-resistant methods and assume that redirect laundering can be part of the attack path.
Related resources from NHI Mgmt Group
- Why do open redirect flaws increase phishing risk in authenticated web applications?
- Why do open redirect phishing attacks often bypass secure email gateways and reputation-based controls?
- What happens after an attacker proxies a real login page during an open redirect phishing attack?
- What is the difference between reflected XSS and open redirect abuse in phishing attacks?