The Vulnerabilities That Matter
Now that you understand how web applications are supposed to work, we can dive into the fun part - learning how to break them.
Vulnerabilities are essentially mistakes in code or logic. Developers are human, and they sometimes forget to check who should see what data or they leave a sensitive file accessible. These mistakes become your opportunities.
Below, we'll break down some of the most common and impactful types of vulnerabilities you will find in the wild, and after completing this course.
Insecure Direct Object Reference (IDOR)
An IDOR is when you can access data that doesn't belong to you, usually by changing an ID number in the URL or an API request. This is one of the most common bugs because it relies on a simple oversight: the application sees a request for order=124 and shows the order description, but it forgets to check if the logged-in user actually made that order.
A similar example that I found in the wild was on an airline website where you could change the ticket ID in the URL to view other people's boarding passes, full names, and flight details - they were all numerical IDs.
Server-Side Request Forgery (SSRF)
An SSRF is where you trick an application's server into making a web request on your behalf. This often happens when a feature takes a URL as input, like importing a profile picture from a link, but fails to validate that the URL isn't pointing to a private, internal server.
A classic example involves a site that let users import a photo from a URL, by providing a special internal address, such as AWS Cloud Metadata (http://169.254.169.254/latest/meta-data) - you can trick the server into requesting its own cloud credentials, granting you access to sensitive cloud infrastructure data of your target.
Subdomain Takeovers
A Subdomain Takeover happens when a subdomain, like store.company.com, points to a third-party service like Shopify or AWS S3 bucket that the company no longer uses, but they forgot to remove the DNS record. As a bug bounty hunter, you can then register that specific resource on the third-party service and take full control. In the final chapter of this course, I'll show you how I was able to hijack a company's main www.company.com domain because it pointed to an unclaimed AWS S3 bucket.
Exposed Files and Leaked Secrets
Sometimes the bug isn't in the application code, but in what's left lying around. Developers might accidentally leave exposed directories like /backup/ or /admin/ or sensitive files such as .env accessible to the public internet.
Similarly, they sometimes commit sensitive information like API keys, passwords, or internal URLs inside public GitHub repositories. These are often quick wins, as finding a backup of a customer database or an API key in public code often leads to a critical finding, without much effort.
Business Logic Flaws
These bugs are often the most creative to find - they aren't a typical technical mistake but a flaw in the application's intended workflow. The application works exactly as it was programmed, but you find a way to abuse its logic.
For instance, imagine a food delivery app where you discover that you can add an expensive item to your cart, apply a 50% discount code, and then reduce the quantity of the expensive item while the large discount amount remains, allowing you to basically get the entire order for free.
Exploiting 0-Days and Novel Misconfigurations
A unique and time-sensitive opportunity for bug hunters comes from the public disclosure of new, widespread vulnerabilities, often called "0-days" or novel misconfigurations.
It all begins when a security researcher discovers a significant flaw in a common piece of software, like a web server, a popular framework, or a widely used cloud service. Typically, the researcher reports this vulnerability to the software vendor privately, allowing them time to develop a patch.
Once a fix is available, the vulnerability is often made public and sometimes also gets assigned a CVE (Common Vulnerabilities and Exposures) identifier. The technical details, including a Proof of Concept (PoC), are then rapidly shared across platforms like X and in detailed technical blog posts.
This is the moment the "gold rush" begins, as malicious attackers immediately start scanning the internet for unpatched systems to exploit, while companies race to apply the fix across their infrastructure. As a bug bounty hunter, you are in a unique position within this race - your objective is to leverage the public information to find and report the vulnerability on your target programs before malicious attackers can exploit it, and before other hunters report the same finding.
Success in this type of hunting is often a matter of speed and efficiency and usually displays a fantastic win-win situation for all parties. You get paid for your efforts, and the programs manage to patch critical findings before malicious actors can act on them - thanks to your report.
Developing Your "Bug Bounty Hunter's Eye"
You don't need to be a programming genius to find the bugs we've just discussed. As you've seen, many of the most impactful vulnerabilities come from simple mistakes and logical flaws.
Success isn't about memorizing every vulnerability in the world; it's about developing a "bug bounty hunter's eye."
This really comes down to a few key traits.
It starts with Curiosity - the constant willingness to ask, "What happens if I try this?" and to poke at features in ways the developers never intended.
Over time, that curiosity builds Pattern Recognition, where you'll start to intuitively spot the kinds of things that often lead to bugs, like seeing numerical IDs in a URL or a file upload feature that might be abusable.
Finally, it requires Persistence - most of your ideas won't work, but the best hunters are the ones who don't give up and keep trying different approaches until they find something.
Mastering these skills is far more important than any single technical trick.
In the next chapter, we’ll move on to "The Power of Community" and learn how collaboration can supercharge your hunting efforts.