From P4 to P1 — Day 5: Open Redirect Vulnerabilities in Bug Bounty Hunting

Introduction

Have you ever clicked a link on a trusted website, only to be redirected somewhere unexpected?

Sometimes, this behavior is intentional. Websites redirect users after login, send them to external documentation, or forward them to a requested page.

But what happens when an application allows an attacker to influence the destination of that redirect?

This is where an open redirect vulnerability may occur.

Open redirects are often considered low-severity findings, but their actual risk depends on the application's behavior, the surrounding authentication flow, and the impact that can be demonstrated.

In previous articles, we explored cookie security, verbose error messages, and technology disclosure. Today, we'll look at how to identify and validate unsafe redirects without exaggerating their impact.

1. What is an open redirect?

An open redirect occurs when an application redirects a user to a destination that an attacker can control, without adequately validating or restricting that destination.

Consider this hypothetical URL:

https://example.com/redirect?url=https://trusted.example

https://example.com/redirect?url=https://trusted.example

The application accepts a url parameter and redirects the browser to the supplied destination.

If the application also accepts arbitrary external destinations, an attacker might create a link that begins with a legitimate domain but ultimately sends the victim elsewhere.

For example, a vulnerable application might accept:

https://example.com/redirect?url=https://attacker.example

https://example.com/redirect?url=https://attacker.example

Here, example.com is illustrative. Use an application you own or have explicit permission to test.

The key question: Can an untrusted user control the redirect destination in a way that violates the application's intended security policy?

Not every redirect parameter is vulnerable. Some applications validate destinations correctly or intentionally support specific external links.

2. Where should bug hunters look?

During authorized web application testing, redirect behavior may be found in several places.

A. URL parameters

Look for parameters with names such as:

• url
• redirect
• redirect_url
• return
• returnUrl
• next
• continue
• callback

These names are clues, not proof of a vulnerability.

B. Login and logout workflows

Applications often redirect users after authentication, logout, password resets, or account changes.

Review whether the application restricts redirect destinations to approved locations, particularly when the flow involves trusted authentication pages.

C. Links and navigation features

Some applications provide external navigation, document links, or forwarding endpoints. Determine whether these features enforce the intended destination policy.

D. Client-side redirects

JavaScript may read URL parameters and navigate the browser to another location. Inspect the relevant code and validate how the destination is constructed.

A redirect implemented in JavaScript can still introduce security problems if it trusts attacker-controlled input.

3. How to validate an open redirect manually

Always perform testing against an authorized target.

Step 1: Identify a redirect parameter

Start with a legitimate application workflow and identify a URL that contains a redirect-related parameter.

For example:

https://example.com/redirect?url=https%3A%2F%2Ftrusted.example

https://example.com/redirect?url=https%3A%2F%2Ftrusted.example

Record the original request and expected behavior.

Step 2: Observe the response

Use browser developer tools or an HTTP client to inspect the response.

For example:

curl -sS -D - -o /dev/null 'https://example.com/redirect?url=https%3A%2F%2Ftrusted.example'

curl -sS -D - -o /dev/null 'https://example.com/redirect?url=https%3A%2F%2Ftrusted.example'

Look for a redirect status code, such as 302 Found, and a Location header.

A redirect response is normal behavior. The important question is whether the destination is being controlled safely.

Step 3: Use a controlled test destination

In a test environment or authorized program, replace the expected destination with a domain you control.

Observe whether the application:

• Rejects the destination
• Redirects only to an approved path
• Normalizes the URL safely
• Accepts an arbitrary external destination

Avoid using deceptive links against real users. You can validate the behavior using your own browser and a controlled destination.

Step 4: Test the validation logic

Check whether the application uses a reliable allowlist or other appropriate destination validation.

Be aware that simple string matching can be misleading. For example, a hostname that merely contains a trusted domain name is not necessarily part of that trusted domain.

The correct validation should examine the parsed destination and enforce the intended host, scheme, and path policy.

Step 5: Document the evidence

Record the original request, the modified test input, the resulting response, and the final destination.

Redact sensitive query parameters, authentication tokens, and personal data before sharing the evidence.

4. Why can open redirects matter?

The security impact depends on context.

A. Phishing and user trust

A link beginning with a legitimate domain may appear trustworthy to a recipient. If the domain then redirects to an attacker-controlled destination, the redirect can make a phishing link more convincing.

However, a phishing scenario alone does not automatically justify a high severity rating.

B. Authentication flows

Redirect behavior can be particularly important around login, OAuth, and other authentication workflows.

If a redirect flaw can be combined with a separate weakness to expose authorization codes, tokens, or sensitive information, the overall impact may be more serious.

Do not assume that every open redirect exposes credentials. Demonstrate the relevant behavior safely before making that claim.

C. Security control bypasses

Some systems rely on approved destinations to maintain trust boundaries. An open redirect may undermine those assumptions if another component treats the initial domain as sufficient evidence of safety.

Whether this creates a meaningful exploit path depends on the specific application and its integrations.

5. How to distinguish a valid finding from a false positive

Consider these three scenarios.

Scenario 1: A restricted redirect

The application accepts a destination only from a predefined list of approved pages.

This is generally expected behavior, provided the validation is implemented correctly.

Scenario 2: An arbitrary external redirect

The application accepts an untrusted destination and redirects the browser there.

This may qualify as an open redirect, depending on the program's policy and the demonstrated risk.

Scenario 3: A redirect that affects an authentication flow

The application accepts an attacker-controlled destination within a sensitive authentication workflow, and further testing establishes that this enables a concrete security impact.

This may warrant a higher severity assessment than a standalone redirect, depending on the evidence.

The lesson is simple: verify the actual destination and determine what the behavior enables.

6. Common mistakes when reporting open redirects

1. Reporting every external redirect as a vulnerability.
2. Assuming a redirect automatically enables account takeover.
3. Failing to inspect the final destination.
4. Relying on weak string matching when assessing host validation.
5. Testing against third-party destinations without authorization.
6. Ignoring program-specific exclusions for low-impact redirects.
7. Assigning severity based only on the vulnerability name.

A professional report should focus on reproducible behavior and evidence-based impact.

7. Sample professional vulnerability report

Title: Open Redirect Through an Unvalidated Destination Parameter

Description:

During the security assessment, the application's redirect endpoint was observed accepting a user-controlled destination and redirecting the browser to an external domain that was not part of the intended destination policy.

This behavior may allow attackers to construct links that begin on the application's legitimate domain but send users to an external destination. The practical risk depends on how the redirect is used and whether it can be combined with other weaknesses.

Steps to Reproduce:

1. Access the authorized application.
2. Identify the redirect endpoint and its destination parameter.
3. Capture the normal request and response.
4. Replace the destination with a controlled external test URL.
5. Observe the redirect response and confirm the final destination.
6. Record the evidence without involving unsuspecting users.

Impact:

An attacker may abuse the trusted domain as an intermediate redirect in phishing or other attack scenarios. Additional impact should only be claimed if demonstrated.

Remediation:

• Prefer relative paths for internal redirects.
• Enforce an allowlist of approved destinations where external redirects are required.
• Parse and validate URLs using a reliable URL parser.
• Reject unexpected schemes, hosts, and malformed destinations.
• Avoid relying on simple substring checks.
• Review redirect behavior in authentication and account-management workflows.

Severity: Informational or Low for a standalone redirect, depending on program policy and context. Reassess if a concrete additional security impact is demonstrated.

8. Day 5 validation checklist

Before submitting an open redirect report, verify that:

• The endpoint is within the authorized scope.
• The destination is genuinely attacker-controlled.
• The redirect is reproducible.
• The final destination is confirmed.
• Existing destination validation has been considered.
• The security impact is realistic and evidence-based.
• The report follows the program's severity guidelines.

Final thoughts

Open redirects are a useful example of why bug hunting requires more than finding unusual behavior.

A redirect can be perfectly legitimate, or it can expose a weakness in how an application establishes trust in its destinations. The difference comes down to validation, context, and demonstrable impact.

Remember: Finding a redirect is easy. Proving that it violates a security boundary is the real work.

This is Day 5 of From P4 to P1: The Bug Hunter's Journey. As the series progresses, we'll continue moving from basic observations toward more complex vulnerabilities and stronger reporting skills.

Coming tomorrow — Day 6: CORS Misconfigurations. When does a cross-origin policy become a real data exposure risk?

Follow along for the next part of the series. :)