Structure of the notes:

• Fundamentals: API mechanics, event properties, mental model (treat listeners like REST APIs)
• Vulnerability classes: 3 main types: no origin check, wildcard sender (data leak), weak origin validation
• Exploit templates: iframe embed, window.open() bypass for X-Frame-Options, OAuth token steal, both real-world CVEs with annotated payloads
• Recon & discovery: all tools across articles: postMessage-tracker, DOM Invader, MessPostage, PMHook, Posta, Untrusted Types
• Testing methodology: 10-step hunt process from discovery to PoC
• Bypass cheatsheet: all 4 regex/string bypass patterns (indexOf, no $ anchor, unescaped ., search() coercion) + escapeHtml bypass
• Dangerous sinks: everything that turns message data into XSS
• Remediation: exact code fixes
• Real-world cases: HackerOne reports with exploit flow explained

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

Im documenting some data as article.

1. PortSwigger Web Security Academy
https://portswigger.net/web-security/all-labs
PortSwigger offers one of the most comprehensive free platforms. Their labs cover everything from basic reflected XSS to advanced cases like DOM-based XSS and WAF bypasses. Each lab comes with guided explanations, making it great for both beginners and advanced learners.

2. Polyglot XSS Cheat Sheet (Archive)
https://web.archive.org/web/20190617111911/https://polyglot.innerht.ml/
This archive contains creative polyglot payloads that work across multiple contexts. Practicing here helps you understand how XSS behaves in different filters and situations.

3. Sudo.co.il XSS Challenges
https://sudo.co.il/xss/
This platform has multiple real-world inspired challenges. It’s hands-on and gives you practical exposure to bypassing sanitization.

4. XSS Quiz (by int21h)
https://xss-quiz.int21h.jp/
A fun quiz-style lab where you need to craft payloads for different scenarios. It starts simple but quickly gets tricky, testing your creativity.

5. Prompt.ml
https://prompt.ml/0
Focused on prompt injection and XSS-like payloads, this is a unique place to experiment with modern attack vectors.

6. Alf.nu — The Classic Alert Game
https://alf.nu/alert1?world=alert&level=alert0
This is an old but gold interactive game where each level requires you to trigger alert(1). It’s fun and addictive while teaching a lot about escaping contexts.

7. Intigriti Bugology
https://bugology.intigriti.io/intigriti-monthly-challenges
Intigriti publishes monthly bug bounty style challenges, often including XSS. They’re closer to real bug bounty scenarios, so great for hunters.

8. YesWeHack Dojo
https://dojo-yeswehack.com/learn/vulnerabilities/xss
A guided learning environment that explains XSS concepts clearly. Best for people starting out or looking to structure their learning.

9. Google XSS Game
https://xss-game.appspot.com/
Google’s classic XSS Game contains a set of levels where you exploit vulnerable applications. It’s simple, effective, and still widely used by learners.

10. Public Firing Range
https://public-firing-range.appspot.com/
A hands-on collection of intentionally vulnerable web apps and scenarios for practicing real-world web bugs (XSS, SQLi, CSRF, open redirects, etc.). Clean, challenge-style exercises with reproducible targets make it great for learning exploitation techniques and safe testing workflows — ideal for beginners → intermediate hunters wanting realistic practice without touching production.

Final Thoughts
Practicing on these labs will strengthen your fundamentals and give you the confidence to spot and exploit XSS in real-world applications. Start with PortSwigger and Google XSS Game if you’re new, then move on to Sudo.co.il and Intigriti Bugology for more advanced, practical challenges.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All sensitive data is blurred due to privacy reasons.

When I first started exploring Web3, I found it confusing to differentiate between blockchains, programming languages, and other common terms. To clear this up for myself (and others who might feel the same), I created this simple table that organizes the most important terminology in one place.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

These resources are for people who already know bug bounty well and want to get better. They are not for beginners.

1. CyberFlow Academy:

Why It’s Good: It has lots of practical lessons and labs. You learn real hacking skills and get help from a private community.

https://cyberflow-academy.github.io/#features

2. PentesterLab PRO:

Why It’s Good: It has many exercises from easy to hard. You learn to find bugs manually and make your own scripts. It also gives certificates.

https://pentesterlab.com/pro

3. Bug Bounty Reports Explained (BBRE):

Why It’s Good: It shows real bug bounty reports and how top hackers find bugs. You learn strategies to report bugs effectively.

https://study.bugbountyexplained.com/

4. Critical Thinking Podcast: How to Go Full-Time Bug Bounty:

Why It’s Good: It teaches how to go full-time in bug bounty. You get advice, steps to follow, and support from a Discord community.

https://www.criticalthinkingpodcast.io/p/how-to-go-full-time-bug-bounty/

5. Udemy: Web3 and Blockchain Security Pen Testing & Bug Bounty Part 1:

Why It’s Good: It focuses on Web3 and blockchain security. You learn about smart contract bugs and testing decentralized apps.

https://www.udemy.com/course/web3-and-blockchain-securitypen-testing-bug-bounty-part1/?srsltid=AfmBOop-UF2iuuXws4imJ_GFFwKCfFRIey-yhl09CpUD92a8kqW_u3Ox&couponCode=MT250908G2

6. Udemy: Offensive Thick Client Penetration Testing:

Why It’s Good: It teaches testing desktop applications, which most courses ignore. You learn to find bugs in thick client apps.

https://www.udemy.com/course/offensive-thick-client-penetration-testing/?couponCode=PMNVD2025

Conclusion:

These courses help experienced bug bounty hunters improve their skills, learn advanced techniques, and get better at reporting and finding high-value bugs.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

So while solving XSS lab in portswigger and I was approaching lab with my bug bounty methodology, this is the lab link: https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink-inside-select-element

The XSS was in the stock check functionality, where I could influence the HTML content directly through the URL. So, I went to that functionality, clicked the “Check Stock” button, and intercepted the request in Burp Suite. Here’s how it looked.

Here are my observations:

• In the dropdown menu, I saw country names.
• In the URL, I noticed the product_id= parameter.
• In Burp Suite, both parameters appeared together, connected with &, like this: productId=2&storeId=London.
• I copied this line, pasted it into the URL, and added my XSS payload after the storeId= parameter value, as shown in the example below.

And boom, XSS! But then I noticed the lab was still not marked as solved. Why? I popped an XSS, right? So, I went to the PortSwigger Discord server and asked if the lab was bugged or not.

Then I went to ChatGPT and asked what I was doing wrong.

And now I finally understood what I did wrong.

This is where the XSS popped up inside the dropdown menu, technically inside the <option> tag. But I’m supposed to escape the <option> tag first and then trigger the XSS. So let’s do that.

Now the lab is solved I escaped the <option> tag using <select>.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All sensitive data is blurred due to privacy reasons.

Target Overview

Target Overview is not relevant to this bug, as it was discovered while testing static resources on the application.

Now Main Story

While casually testing some endpoints, I came across a file hosted on the domain redacted.com.

The file was being served from an Amazon S3 bucket, but when I accessed it directly, I got a simple Access Denied error. Nothing unusual at this point.

Out of curiosity, I appended a jsessionid parameter to the request. Surprisingly, the response was totally different this time. Instead of a plain denial, the request triggered Amazon’s Signature V4 signing process, and since the signature didn’t match, the error message revealed a lot more details than expected.

The verbose XML response exposed:

• The AWS Access Key ID (partially).
• The Signing algorithm being used.
• The Region (us-east-1).
• Most importantly, the S3 bucket name → redacted-www-live.

appended a jsessionid parameter to the request.
Instead of a simple denial, the backend (or proxy in front of S3) tried to sign the request using AWS Signature v4.
Since my jsessionid didn’t match what the app expected, the request failed with SignatureDoesNotMatch.
But this failure returned debugging details in the XML error:
AWSAccessKeyId (partially exposed).
The StringToSign and CanonicalRequest (shows signing process).
The Host header → XXXXXXXXX.s3.amazonaws.com.
→ This directly leaks the S3 bucket name (XXXXXXXX).

Why This Matters

Normally, users should only see a plain access denied message. But due to this misconfiguration, just appending a parameter (jsessionid) forced the backend to handle the request differently and leak internal AWS storage details.

This might not directly allow full compromise, but such information disclosure is very useful for attackers during reconnaissance and can help in chaining bigger bugs like bucket takeover or privilege escalation.

Learnings

1. Never rely on default error handling for signed requests.
2. Always sanitize and restrict error messages exposed to end users.
3. Even a simple parameter change can reveal critical internal details.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

My Introduction

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All sensitive data is blurred due to privacy reasons.

Target Overview

Target Overview is not relevant to this bug, as it was discovered in a common functionality known as the “Forgot Password” page.

Now Main Story

I received a fresh private invite on YesWeHack, and luckily, at that time, I was learning Android pentesting while also looking for a new Bug Bounty program with an Android app in scope. As soon as I saw the invite, I checked the scope and found an Android app. I installed it in my emulator, bypassed root detection and SSL pinning, and directly started API/Dynamic testing.

After testing for basic API bugs, I was super tired then I opened my checklist in notion page

and started with forgot password functionality.

My hunting approach while testing any specific xyz functionality

1. clean burp history
2. Go to the desired functionality (e.g., signup, forgot password, invite user), run it through the proxy, and use it as a normal user.
3. analyse burp traffic
   what Specific I do in “analyse burp traffic”
   1. Checking how many API calls being made by that specific functionality.
   2. What data being taken to server in request and what data being servered by the server in response to me ?
   3. what and how many parameters being used ? can I do IDOR ? can I do SQLI ?, Can I do Mass assignment etc…………..
4. Then I look for any anomaly

Back To Story

so while testing I entered my email and analyse the request and response in burpsuite

Wait what the password reset token doing in response ?
is it temporary token ?

what let me check password reset link i got on my mail

wait WTFFFFF both token are exact sameeee!!

Now, I just need to add the victim’s email in the request, extract the password reset token from the response, and insert it as the value of the pwrt parameter.

So now its time for $9999999999 bounty for my critical bug right ?

NOOOOOOOO!!!!!

After a month of continuous discussions, they finally sent me a message stating that since the attacker needs to bypass root and SSL pinning, the attack complexity is high. Therefore, they categorized the bug as High instead of Critical with a payout of only $1000. However, due to my patience and the live session I provided (they asked me to demonstrate the exploitation on Google Meet), they decided to give me as $400 bonus.

Learn Android Bug Bounty

you can always refer to my gitbook where i mentioned tone of free resources there is no perfect roadmap so start reading articles and watching video from this list

Video Tutorials | Biscuit's Bug Bounty Playbook

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya, I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All sensitive data is blurred due to privacy reasons.

Target Overview

Redacted is a platform that provides blog articles, tutorials, and resources for developers. Users can create accounts to interact with content, such as posting comments. To maintain authenticity, the platform requires users to verify their email before gaining full access to certain features.

Now Main Story

While testing the platform, I noticed that unverified users couldn’t post comments and were asked to verify their email first.

I decided to analyze the JWT tokens issued during registration.

• The unverified account’s JWT had a few extra claims compared to the verified one.

• After clicking the official verification link, I noticed its structure:

https://example.com/auth/verify-email/<JWT_TOKEN>

This gave me an idea: what if the verification endpoint accepted any valid session JWT?

So, I created a new account, intercepted an authenticated request (like a page refresh), copied the session JWT, and pasted it into the verification URL:

https://example.com/auth/verify-email/<SESSION_JWT>

Boom, the account got verified instantly, without ever needing to open the verification email.

This completely bypassed the intended email ownership check.

I will add poc video link as soon as bug will fixed

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All The Sensitive Data is blurred Due To Privacy Reason

Target Overview

The target was known to me for a very long time, and I tested every domain and app in scope.
After testing the whole scope, I noticed a pattern: for each of their products, I needed to create a separate account using the same email, as there was no single unified account across all their products.
The main point is that all the endpoints which send OTPs or any kind of emails are protected with rate limiting, but not securely enough they allow sending around 10 emails to the inbox before applying rate limits. So, what I did was gather all the endpoints and note them on a single Notion page.

On that page, I only mentioned 3 endpoints, but in reality, there were 5 endpoints without any authentication or cookies. I created a bash script that takes the victim’s mobile number and sends OTPs from each endpoint until the rate limit is hit. Since each endpoint allows around 10–12 OTPs, I was able to send about 50 OTPs in total by leveraging all endpoints, effectively allowing me to spam the victim.

For this bug they paid me like 15k INR which is roughly 170 dollar for p4 level bug I think its totally fare amount

Quick Update After Posting This Writup

After a long conversation with my fellow hunter friends, I realized this bug is generally not accepted in bug bounty programs, and I was a bit lucky to get a bounty for it. So, kindly don’t report the same issue in other programs, as you might not be lucky enough to get a bounty for such a minor bug.

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Hiyya I am Raunak Gupta, a Security Researcher and Bug Bounty Hunter for fun and profit.

All The Sensitive Data is blurred Due To Privacy Reason

Target Overview

Redacted.com is a cloud-based cryptocurrency trading bot platform that automates trades using technical indicators, signals, and strategies.

Context Behind Email Alias Normalization

In bug bounty, email alias normalization is important because many providers like Gmail treat addresses with dots (r.andom@gmail.com = random@gmail.com) or plus tags (random+1@gmail.com) as the same account. If a system fails to normalize these, attackers can bypass restrictions such as free trial limits, one-account-per-user rules, or rate limits. This leads to abuse, revenue loss, and broken business logic, making it a valuable finding for bounty hunters.

Now Bug Bounty Story

While testing, I was frustrated by the 3-day trial limit since I had to create a new account each time. Then I wondered if I could manipulate my email so the system would treat it as a different address, while still receiving all messages in the same inbox. Gmail makes this possible through email aliases, which are variations of the same address that still deliver to one inbox. For example:
Random@gmail.com
ra.ndom@gmail.com
random+test@gmail.com
random@googlemail.com

All go to the same Gmail account. Attackers often exploit this in apps that don’t normalize aliases, to create multiple accounts or bypass restrictions.

So now I can use the same email with aliasing to get unlimited trials. There is no screenshot because there’s really nothing to show it’s just a technical writeup.

Note

After publishing this writeup, I received multiple messages saying it was just a P5-level bug. I realized the writeup wasn’t really valuable or informative for the community

Connect with me

LinkedIn: https://www.linkedin.com/in/raunak-gupta-772408255/
My Discord server: https://discord.gg/8SSx5Ma9ve
My YouTube Channel: https://www.youtube.com/@BiscuitSecurity/featured

Unlimited Trials: Exploiting Email Alias Normalization in Redacted.com was originally published in OSINT Team on Medium, where people are continuing the conversation by highlighting and responding to this story.