From Open Redirect to Cookie Bombing: How I Chained Two Web Security Issues

During a bug bounty assessment, I found an Open Redirect in an authentication-related flow. While investigating its practical impact, I discovered that the redirect could be chained with browser cookie behavior to demonstrate a cookie-bombing / header-bloat scenario.

For responsible disclosure, I'll keep the target anonymous and refer to it as the target application.

1. Finding the Open Redirect

The application had an authorization endpoint that accepted a redirectURL parameter:

https://target.example/authorization?authPage=login-options&redirectURL=<external-url>

https://target.example/authorization?authPage=login-options&redirectURL=<external-url>

What is an Open Redirect?

An Open Redirect happens when a website allows an attacker to control where the user's browser is redirected.

Normally:

Target Website → Trusted Page

Target Website → Trusted Page

But with an open redirect:

Target Website → Attacker-Controlled Website

Target Website → Attacker-Controlled Website

This can be useful for phishing because the initial URL belongs to a legitimate and trusted domain.

In my case, I tested the redirectURL parameter with a domain that I controlled, and the application successfully redirected the browser there.

The flow was:

Victim
   ↓
Target Application
   ↓
Authorization Flow
   ↓
redirectURL
   ↓
My Controlled Domain

Victim
   ↓
Target Application
   ↓
Authorization Flow
   ↓
redirectURL
   ↓
My Controlled Domain

This is classified as CWE-601: URL Redirection to Untrusted Site.

Impact of the Open Redirect

The main impact was the ability to use the trusted target domain as a redirector to an attacker-controlled website.

This can make malicious links appear more trustworthy because the victim initially sees a legitimate domain before being redirected elsewhere.

For example:

Trusted Domain
      ↓
Authentication Flow
      ↓
Attacker-Controlled Page

Trusted Domain
      ↓
Authentication Flow
      ↓
Attacker-Controlled Page

This can potentially be abused for:

• Phishing
• Credential-harvesting campaigns
• Social engineering
• Redirecting users to malicious content
• Bypassing some basic URL-reputation or domain-trust checks

However, in my testing, I could not demonstrate token leakage, credential theft, or account takeover. Therefore, those impacts should not be claimed as confirmed.

2. Checking for Sensitive Information

Because the redirect happened during an authentication-related flow, I checked whether anything sensitive was being sent to my controlled domain.

I tested for:

• Session tokens
• Authentication codes
• OTP information
• User information
• Sensitive URL parameters
• Useful Referer information

I could not confirm any token, session, or personal-information leakage.

So I did not claim account takeover or credential theft.

Instead, I investigated whether the redirect could be combined with another browser-side behavior.

3. Redirecting to My Controlled Domain

The interesting part was that the redirect destination was under my control.

My controlled page contained a cookie-bombing proof of concept.

Before explaining the chain, it is important to understand what cookie bombing means.

4. What Is Cookie Bombing?

A cookie is small data that a website stores in a user's browser.

For example:

theme=dark
session=abc123

theme=dark
session=abc123

The browser automatically sends matching cookies back to the website with future requests.

Cookie bombing is a technique where a large amount of cookie data is stored for a target domain, causing the browser to send a large Cookie header with subsequent requests.

The basic idea is:

Large Cookies
     ↓
Large Cookie Header
     ↓
Request Becomes Too Large
     ↓
Server / Proxy Rejects Request
     ↓
HTTP 400

Large Cookies
     ↓
Large Cookie Header
     ↓
Request Becomes Too Large
     ↓
Server / Proxy Rejects Request
     ↓
HTTP 400

Depending on the application's infrastructure, this can cause access disruption for the affected browser.

Impact of Cookie Bombing

If the resulting cookie data is large enough to exceed the target's request-header limits, the affected browser may repeatedly receive errors when accessing the application.

This can result in:

• Temporary loss of access to the website
• HTTP 400 responses
• Disruption of login or account pages
• Persistent browser-side disruption until the affected cookies/site data are removed

If cookies are scoped broadly enough, the effect may also extend to multiple applicable subdomains.

However, the actual impact depends heavily on the browser, cookie scope, CDN/proxy configuration, and server header limits.

5. The Chain

My controlled domain contained a cookie-bombing proof of concept.

Conceptually, the complete chain was:

Victim opens trusted URL
          ↓
Open Redirect
          ↓
My Controlled Domain
          ↓
Cookie-Bombing PoC
          ↓
Browser Cookie Storage
          ↓
Large Cookie Header
          ↓
Request Rejected

Victim opens trusted URL
          ↓
Open Redirect
          ↓
My Controlled Domain
          ↓
Cookie-Bombing PoC
          ↓
Browser Cookie Storage
          ↓
Large Cookie Header
          ↓
Request Rejected

The important technical detail is that the browser still enforces cookie rules. My controlled domain did not simply gain access to the target's JavaScript origin.

The cookie's domain, path, and browser behavior determine whether it will actually be sent with requests to the target.

6. What I Verified

I separated the confirmed behavior from assumptions.

Confirmed

• External redirection was possible.
• The redirect could lead to my controlled domain.
• My controlled page could execute my test JavaScript.
• Cookie behavior could be tested.
• Oversized request headers can result in request rejection.

Not Confirmed

• Account takeover
• OTP bypass
• Session-token theft
• Credential theft
• Private user-data exposure

7. The Important Bug Bounty Lesson

Unfortunately, the cookie-bombing / DoS portion of this chain was considered out of scope by this particular program.

And this is something researchers should always check before testing.

Different bug bounty programs have different policies.

Some programs may accept certain types of availability or resource-exhaustion issues under controlled conditions, while others explicitly exclude:

• DoS
• DDoS
• Resource exhaustion
• Stress testing
• Excessive automated requests
• Availability-impact testing

So even when a technique is technically valid, it doesn't necessarily mean it is reportable under every program's rules.

In this case, the program specifically excluded DoS/DDoS-style impact, so I treated the cookie-bombing portion as a technical research observation rather than relying on it as the primary report impact.

8. Remediation

Fix the Open Redirect

Validate redirectURL server-side and allow only trusted internal paths or explicitly allowlisted domains.

Review Cookie Scope

Use the narrowest appropriate cookie domain and path. Avoid unnecessarily broad parent-domain cookie scopes.

Protect Against Header Bloat

CDNs, reverse proxies, and web servers should enforce sensible request-header limits and handle oversized requests safely.

Final Takeaway

What started as a simple Open Redirect turned into an interesting investigation into browser cookie behavior.

The research chain was:

Open Redirect → Controlled Domain → Cookie Behavior → Header Bloat → Request Rejection

But there is another important lesson beyond the technical side:

A technically valid security impact is not automatically a valid bug bounty impact.

Always read the program's scope before testing. Some programs accept certain availability issues, while others explicitly exclude them.

For me, the valuable part was understanding the chain and learning where the boundary between technical impact and program-accepted impact lies.

Find the behavior. Understand the mechanism. Check the scope. Prove what is actually reportable.