.png)
1 day ago
9 BOOK THIS SPACE FOR AD
ARTICLE AD
When I first started bug bounty hunting, I had no idea how long it would take to find my first real vulnerability. After three years of learning, trying, and failing, I finally landed my first pay-out — $500 for a Denial of Service (DoS) vulnerability!
In this writeup, I’ll walk you through how I discovered this bug, from basic recon to uncovering a flaw that could allow an attacker to block real customers from using a company’s product. If you’re new to bug bounty hunting, don’t worry — I’ll explain everything in simple terms so you can learn from my experience.
I began with some recon and subdomain enumeration. During my search, I discovered a subdomain that allowed users to sign up for a free trial. I went through the process — entering my email, password, and payment details — which eventually led me to an endpoint that required a special ID I will be calling the “required ID”.
I did some OSINT on the target to figure out what this ID was. I learned that the required ID is found only on the physical product that the company sells. Since I didn’t own the product, I assumed I’d hit a dead end. However, when I started typing random characters into the required ID input field, the webpage immediately displayed an error message: “Invalid Required ID.” What caught my attention was that this error appeared as soon as I typed — it didn’t require me to press the register button or reload the page.
This behaviour suggested that the validation was happening on the client side (in the browser) via JavaScript rather than on the server. With my basic web knowledge, I suspected that the site was using a JavaScript function to check if the ID was valid. I copied the error message (“Invalid Required ID”), opened the browser’s developer tools (pressing F12), navigated to the Sources tab, and searched for any JavaScript file that contained this error message. I figured that file would also handle the validation.
I found the file that contained the error message and discovered that it wasn’t making any request to an external service or database to check the validity of the ID. Instead, it was simply using a regular expression (regex) to validate the required ID. If the entered ID didn’t match the regex pattern, the register button would be disabled, and the “Invalid Required ID” error message would appear. The function that validated the ID with the regex behaved something like this :
// Client-side validation for the required IDconst requiredIdRegex = /^R[XYZ]\d{7}$/i;
if (!requiredIdRegex.test(inputId)) {
alert("Invalid required ID");
}
I copied the function containing the regex and used ChatGPT to help create a JavaScript snippet that could generate a “valid” required ID based on the regex pattern:
// Generate a valid required ID (format: R[XYZ] + 7 digits)function generateRequiredId() {
const prefix = 'R' + ['X', 'Y', 'Z'][Math.floor(Math.random() * 3)];
const digits = String(Math.floor(Math.random() * 10000000)).padStart(7, '0');
return prefix + digits;
}
console.log('Required ID:', generateRequiredId());
I ran the script in my browser console, copied and pasted the generated required ID into the input field and — voilà! — the error didn’t appear, and the register button was enabled. I clicked it, and the registration went through. This confirmed that the server was not performing any validation for the IDs.
After registration, I was directed to a page with a link to download their mobile app. I downloaded the app and logged in with my new account; everything worked as expected.
At this point, as a beginner, I wasn’t sure if this was a vulnerability worth reporting. I wondered, “So what if I can generate ‘fake’ IDs and have them stored in the database? How is that impactful?” Unsure of the next step, I turned to a Discord server filled with bug hunters of all levels. I described my situation, and the server owner himself provided invaluable advice.
He suggested checking whether it was possible to cause a Denial of Service (DoS) by registering all the possible combinations of a valid required ID. Since the IDs were validated using a regex, there was a finite number of combinations. I went back to the site, attempted to register a new account, but this time I used the required ID I already generated earlier, and received a message stating, “ID already registered with an account.” This indicated that each required ID could only be used once, confirming the potential for a DoS vulnerability.
If an attacker were to write a script that continuously generates valid required IDs and registers them, they could eventually exhaust all possible combinations allowed by the regex (roughly 30 million). I further validated the vulnerability by doing more OSINT on the purpose of the required ID. I learned that the ID is found on the product’s packaging and is used to “pair” the physical product with the mobile app. Each product has a unique required ID, meaning that if an attacker registers all available IDs, new customers would be unable to pair their freshly purchased products with the app — a true DoS attack.
I quickly reported this as a high-severity finding. Although it was later reduced to medium severity, I was paid $500 for my discovery — my first bounty and vulnerability found since I started bug bounty hunting three years ago (phew!).
- Explore the Client Side:
While tools like Burp Suite are great for intercepting requests, don’t forget to open your browser’s developer tools to understand how a website works without much server communication. Always use this insight wisely and ethically.
- Ask for Help:
I wasn’t sure how impactful my finding was until I reached out to the bug hunting community on Discord. Their support helped me see the full potential of the vulnerability. If you’re ever uncertain, ask your peers — they’re usually very welcoming.
Here’s an invite link to the discord server I found help at: https://discord.gg/4x8TP4cf
Thank you for reading my first-ever web security writeup. Have a great day (or night)!
Bengali (Bangladesh) · 
English (United States) ·