Bug Bounty Series — Part 2 (Open Redirect)

Inside: A deep dive into the lessons learned and techniques applied during my latest hands-on experiments.

Aditya Kumar

~9 min read · April 25, 2026 (Updated: April 25, 2026) · Free: Yes

Open Redirect

How Open Redirects work:

What is an Open Redirect?

An open redirect happens when a website sends you to another website based on user input, but does not properly check where it is sending you. Attackers can misuse this to send users to malicious (bad) websites.

How Redirects Normally works?

Many websites redirect users on purpose. For example:

· You click a link on a website

· The website sends you to another page or another site

This is often done using a URL parameter.

How Attackers Abuse Open Redirects?

If the website does not check whether the redirect URL is safe, an attacker can change it.

Trying to abuse it on google.com: https://www.google.com/?redirect_to=https://www.gmail.com

Clearly, the google search engine page appeared rather than gmail.com. Google does NOT have a redirect parameter called redirect_to on its homepage. This means Google is not vulnerable in this case.

Note: Just adding ?url=… does NOT mean you are testing an open redirect. You are testing only if the website actually uses that parameter for redirecting

Common Redirect Parameter Names

When looking for open redirects, attackers and security testers look for URL parameters like:

· url=

· redirect=

· next=

· dest=

· r=

· u=

Sometimes the names are not obvious, and each site may use different names.

Redirects Using HTML <meta> Tags:

Websites can also redirect using HTML meta tags, like this:

<meta http-equiv="refresh" content="0; url=https://www.google.com/">

This means:

· Wait 0 seconds

· Then redirect to google.com

If an attacker can change or inject this tag, they can redirect users to any site they want.

Redirects Using HTML <meta> Tags example:

main.html:

Output:

At start: main.html actual output

After time: redirected to the google.html

Checking if the open redirects are allowed: (Trying on http://testphp.vulnweb.com/)

Visit the page:

Open the 'Inspect' section: look for <meta> tag

This can be seen:

There is NO <meta http-equiv="refresh"> tag in that <head>. It does not redirect.

Now, we will check the "Network" tab:

Clearly, 200 is there, so no server-side redirect.

If redirection have to happen then the following things will be observed:

Would show:

· 301, 302, 307

· Location: header

Checking if the redirects are allowed for the website we created:

main.html:

Output:

At start: main.html actual output

After time: redirected to the google.html

Network tab: at start

Network tab: after redirection

Clearly, the network tab changed, it indicates that redirection happened. Since, it is client side, so it is not open redirect.

Note: Open redirect exists ONLY when the user can change where the redirect goes.

Attacker able to change the meta tag:

Main.html:

Clearly, when this opens in browser, it redirects to some home.html. This indicated redirects (not open redirect yet).

Now, what we can do is we can pass a parameter:

Original: http://127.0.0.1:5500/main.html?

Added parameter: http://127.0.0.1:5500/main.html?url=https://example.com

So, what actually happened when we did this to our website? It redirected to the example.com This indicates open redirect.

Note:

Simply changing a URL to ?url=… or ?redirect_to=… does not mean you are testing an open redirect unless the application actually performs a redirect using that parameter.

To actually test for open redirect:

Dashboard.html:

So, when we open the location in the browser: http://127.0.0.1:5500/login.html?next=/dashboard.html

Output:

The Page shows "Logging you in…" and then Redirects to dashboard.html. This means redirect exists.

Now, we will test if open redirect exists or not. For this we changed the url to this :

http://127.0.0.1:5500/login.html?next=https://example.com

Output:

What happens?

· Page shows "Logging you in…"

· Redirects to example.com

Note:

1. An open redirect occurs when an application allows user‑controlled input to redirect users to arbitrary external websites.

2. We only check for open redirects on URLs or pages that already perform a redirect. If a page does not redirect at all, there's nothing to test for open redirect.

Checking the meta based open redirect using the burp suite:

Use the login.html and dashboard.html created above.

Step1: open the burp and open the file location http://127.0.0.1:5500/login.html in the burp browser. Automatically, it will redirect to the dashboard.html. This thing can be seen in Proxy-> HTTP history.

Browser:

Step2: Now, try to open the following link:

http://127.0.0.1:5500/login.html?next=/dashboard.html

Burp can see this redirection:

Step3: send that request to the "repeater".

Step4: Change the "Request" section in the Repeater tab from dashboard.html to example.com. This will check for open-redirection.

Step5: Click on "Send" button. The result came as 200. It means OPEN REDIRECT CONFIRMED.

Why that index.html was vulnerable?

This code is not good because it automatically redirects the user to whatever URL is provided in the next parameter without checking if it is safe. Since anyone can change the next value in the link, the page can be made to redirect users to any external website, not just pages inside the application. This allows attackers to misuse the trusted website as a "jump page" to send users elsewhere without warning, which is known as an open redirect vulnerability. The problem is not the redirect itself, but the fact that the redirect destination is fully controlled by user input and is not validated or restricted.

Fixed version of index.html:

This version is fixed because it no longer trusts whatever URL the user provides. Instead of redirecting to any value found in the next parameter, the code first checks that the requested destination is one of a small list of allowed internal pages. If the value is not in that list (for example, an external site like https://example.com or a fake path), the code ignores it and safely redirects to /dashboard.html instead. This prevents attackers from abusing the page to send users to malicious or external websites, which removes the open redirect vulnerability even though a META refresh is still used.

Testing on safe index.html:

For URL: http://127.0.0.1:5500/login.html?next=/dashboard.html

Redirection Allowed (because it was listed in 'allowedPages' section)

For URL:

http://127.0.0.1:5500/login.html?next=https://example.com

Redirection allowed. But redirection to any other website except dashboard.html, profile.html, settings.html is Not allowed (instead it redirected to dasboard.html).

For the URL: http://127.0.0.1:5500/login.html?next=https://example.com

Output:

Hence, safe from open redirect. As the application only allows redirection to predefined internal paths and ignores external or untrusted destinations.

What Are JavaScript Redirects?

JavaScript can tell the browser to go to another website using code like:

window.location = "https://www.google.com/"

window.location.href = "https://www.google.com/"

window.location.replace("https://www.google.com/")

This Is NOT a Normal Open Redirect:

· Open Redirect- Server tells browser to redirect

· JS Redirect- Injected JavaScript forces redirect

Performing JS redirects on the local website:

Index.html: