From PortSwigger Labs to my First Real-World Bounty: How a Stored XSS Found Me

The Plot Twist in My Study Routine

It was a regular day of studying web security. I was deeply focused, solving hands-on challenges on PortSwigger Web Security Academy, trying to master Cross-Site Scripting (XSS). Like any good student, I had a popular note-taking and productivity app open on the side, where I was documenting my notes, payloads, and observations.

Then, something strange happened.

I generated the public link to share it with my friends so they could benefit from my notes, just like I always do. But as soon as the page loaded, my screen suddenly popped up with multiple JavaScript alert() boxes!

I blinked. I wasn't on PortSwigger's sandbox anymore. I was looking at a live, real-world application executing my test code.

As the title of this article suggests, I had just found my very first real-world vulnerability.

Channeling My Inner Detective: The Bug Chose Me

In the bug hunting world, people spend hours scanning targets. But in this case, as a true beginner at that moment, the bug chose me — I didn't go looking for it.

Once the shock wore off, I immediately switched into detective mode. My very first step wasn't even about looking at the code — I just needed to check if this platform had a Bug Bounty or a responsible disclosure program. Fortunately, they did! Knowing that they welcome security reports gave me a huge green light and the motivation I needed to dig deeper.

Breaking Down the Code: Why Did it Trigger?

To find out exactly why this was happening, I didn't just guess or throw random payloads. I opened the browser's developer tools to look closely at the source code of the page. I needed to see how the website was handling my text.

When I inspected the code, I saw something interesting. The website was taking my notes and dropping them right into an HTML block that was already filled with other scripts.

The main problem was the context. The website treated my input as if it were part of its own code, not just plain text. It didn't properly "clean" or escape the characters.

To make my code run, I had to logically break out of the website's existing code context. After mapping out how the tags were nested, I made a very specific payload to manually close their open sections first:

HTML

</script>
</script><script>alert(0)</script>

</script>
</script><script>alert(0)</script>

Here is how the browser read the payload:

• The First two </script> tags: These forced the browser to close the website's internal script blocks early. This changed the rules; the browser now thought it was back in the main HTML body, not inside a script.
• The New <script> tag: Because I had cleared the way, the browser now saw my injected tag as a new, legitimate command.
• Execution: The browser parsed and ran alert(0) immediately.

This proved that the bug was caused because the application wasn't properly encoding my data before putting it into a sensitive part of the HTML.

I packaged my findings, recorded a quick Proof of Concept video, and submitted my very first security report. Within days, the security team validated the findings, triaged the issue, rated it as a Medium Severity, and rewarded me with my first official financial bounty!

The Lessons Learned

What started as a simple study session turned into a memorable moment in my cybersecurity journey. It taught me that bugs aren't always hidden behind crazy systems; sometimes, they are right there in the apps we use every day to take our notes.