Open Redirects: How Attackers Abuse Your Website’s Links

Short answer: An open redirect is a page on your website that forwards visitors to whatever address is given in a URL parameter, such as ?next= or ?url=, without checking it. Attackers use it to make phishing links look like they point to your trusted domain. Fix it by redirecting only to relative paths or to an allow-list of approved destinations, and by rejecting everything else.

What an open redirect is

Many websites have legitimate reasons to redirect visitors based on a parameter. After login, a site sends you back to the page you came from. A newsletter tracks clicks and then forwards you to the article. A language switcher returns you to the same page in another language. These features often work with a URL like this:

https://example.com/login?next=/account/orders

The problem starts when the code accepts any value, including full URLs on other domains:

https://example.com/login?next=https://evil.example/login

If the site blindly sends the visitor to that address, it is an open redirect. Your domain becomes a launch pad that anyone can use to send people anywhere. The weakness is listed as CWE-601 in the Common Weakness Enumeration, and the OWASP project keeps a dedicated cheat sheet on unvalidated redirects.

How attackers abuse open redirects

An open redirect does not let an attacker read your database or change your pages. Its value lies in borrowing your reputation. Typical abuses include:

• Phishing. A link in an email starts with your real domain, so it passes a quick glance and many link checks. The visitor lands on a fake login or payment page that copies your design.
• Bypassing filters. Some spam filters, chat apps and ad platforms judge a link by its first domain. A trusted domain with an open redirect can carry a malicious destination past them.
• Stealing login tokens. In single sign-on and OAuth flows, a redirect that accepts any destination can leak authorisation codes or tokens to an attacker’s site. This turns a “low” issue into account takeover.
• Chaining with other bugs. Open redirects are often one link in a longer attack, for example to bypass a server-side request filter that only allows your own domain.
• Search and reputation damage. Spammers sometimes mass-produce links through open redirects. If your domain becomes associated with phishing, browsers and email providers may start warning about it.

The last point matters for small businesses. A “Deceptive site ahead” warning or a blocklisted domain hurts far more than the redirect itself. If that ever happens, our guide on removing the Deceptive Site Ahead warning explains the recovery.

Where open redirects usually hide

Look for any feature that takes a destination from the request. Common places are:

• login, logout and registration pages with parameters such as next, return, returnUrl, redirect_to or continue;
• click-tracking scripts like /out?url= or /go.php?link=;
• language and currency switchers that return to a “referrer” page;
• payment and checkout return pages;
• old plugins and themes that implement their own redirect helpers;
• URL shortener or “external link” warning pages built into forums and comment systems;
• JavaScript that reads a value from the URL and sets window.location, a client-side variant that server logs may not reveal.

Custom code and older add-ons are the usual culprits. Mature platforms tend to validate their built-in redirects, but every extra plugin can bring its own. Marketing tools are worth a second look as well, because tracked links in newsletters and ads often pass through a redirect script on your domain.

How to test your site for open redirects

Only test websites you own or are authorised to test. A basic manual check takes minutes:

1. List redirect parameters. Browse your site, log in and out, switch languages, and note every URL that contains a parameter holding a path or address.
2. Replace the value with an external domain. Use a harmless domain you control or a reserved example domain, for example ?next=https://example.org/.
3. Try common bypass forms. Weak filters often fail on variations such as //example.org, https:example.org, /\example.org, an encoded %2F%2Fexample.org, or https://yoursite.com.example.org.
4. Watch where you end up. If the browser lands on the external domain, the redirect is open. Use the browser’s network panel to see the Location header.
5. Check JavaScript redirects too. Search your front-end code for location.href, location.replace and window.open fed by URL parameters.

For larger or custom applications, open redirects are part of a proper vulnerability assessment. Our article on security scans versus penetration tests explains when you need a professional test.

How to fix an open redirect

The fix belongs in the code that performs the redirect. In order of preference:

1. Remove the parameter. If the destination can be stored on the server, for example in the session, do that and do not accept it from the URL at all.
2. Use identifiers instead of URLs. Pass ?dest=orders and map it to a known path on the server. Unknown identifiers fall back to a safe default page.
3. Allow only relative paths. Accept values that start with a single / followed by a path character, and reject anything starting with // or /\, or containing a scheme like https: or javascript:.
4. Use an allow-list for external destinations. If you must redirect to other domains, compare the parsed host exactly against a list of approved hosts. Never use “contains” or “starts with” checks on the raw string.
5. Use framework helpers. Many frameworks and CMSs include safe redirect functions. WordPress, for example, has wp_safe_redirect(), which only allows hosts on an approved list, unlike the plain redirect function.
6. Show an interstitial for external links. Where users genuinely post links to other sites, show a page saying “You are leaving our site” with the full destination visible.

Prevention habits for the long run

• Review plugins and custom code. When you add a plugin with redirect features, test it once with an external destination.
• Keep software updated. Open redirects are regularly fixed in plugin and CMS updates; outdated versions keep them open.
• Log redirect use. Unusual volumes of hits on a redirect endpoint with external destinations are a sign of abuse.
• Protect your domain’s reputation. Set up SPF, DKIM and DMARC so attackers cannot also send email in your name, which makes phishing with your domain much harder.
• Include redirects in your security checklist. Our website security audit checklist lists the other checks worth repeating after every major change.

Common mistakes when fixing open redirects

• Checking only that the URL starts with your domain. https://yoursite.com.evil.example also starts with it.
• Blocking only http and https. Protocol-relative //evil.example still leaves your site.
• Decoding once. Double-encoded values can slip past a filter that decodes the input a single time.
• Fixing the server but not the JavaScript. Client-side redirects need the same validation.
• Treating it as harmless. In login and SSO flows an open redirect can expose tokens. Fix it rather than accept the risk.

How Site AI Audit helps

Site AI Audit checks your website from the outside, the way visitors and search engines see it: the SSL certificate and its expiry, the HTTP to HTTPS redirect, security headers and exposed software versions, plus redirects and broken links found while crawling. It does not attack your application or test parameters for open redirects, which is the job of a code review or penetration test. What it gives you is a ranked list of the security basics to fix first, with plain-language instructions. You can run a free check or compare plans with monitoring on the pricing page.

Related reading

• Cross-Site Scripting (XSS) Explained for Website Owners
• CSRF Explained: How Cross-Site Request Forgery Works
• Email Spoofing: How to Stop People Sending Mail as Your Domain
• Outdated Plugins and CMS Versions: A Safe Update Strategy

The bottom line

An open redirect turns your trusted domain into a tool for phishing and token theft. Find every place where your site redirects based on a parameter, test it with an external address, and change the code so it accepts only known identifiers, relative paths or an exact allow-list of hosts. It is usually a small fix, and it protects both your visitors and your domain’s reputation.

SSS

Is an open redirect a serious vulnerability?

On its own it is usually rated low to medium, because it does not expose your data directly. It becomes serious when combined with login or single sign-on flows, where it can leak tokens, and it can damage your domain’s reputation if used in phishing campaigns.

Do redirects in my .htaccess or server config create open redirects?

Normally not. Fixed redirects from one of your URLs to another are safe. The risk comes from redirects whose destination is taken from user input, such as a URL parameter, without validation.

Can Google penalise my site for an open redirect?

Google does not rank sites lower for having a redirect bug, but if attackers use it for phishing, Safe Browsing may flag the abused URLs and show warnings to visitors. Fixing the redirect quickly avoids that risk.

How do I test for open redirects safely?

Only test sites you own or are authorised to test. Replace the redirect parameter value with an external domain you control or a reserved example domain and see whether the browser leaves your site. Never point tests at real third-party sites.

Does WordPress protect against open redirects?

WordPress core uses safe redirect functions for its own login and admin flows. Plugins and themes, however, can implement their own redirects, so each add-on with redirect features should be tested and kept up to date.