Bug Bounty Hunting Bootcamp

Every vulnerability you will ever find is a consequence of how the web was designed. HTTP is stateless, text-based, and built on trust assumptions that attackers exploit constantly. Understanding the full request-response cycle — at the byte level — is what separates hunters who find critical bugs from hunters who only find the same XSS everyone else reports.

Start with HTTP. A browser sends a request with a method (GET, POST, PUT, DELETE, PATCH, OPTIONS), a path, headers (Host, User-Agent, Cookie, Authorization, Content-Type), and optionally a body. The server returns a response with a status code, headers, and body. Every single field in this exchange is attacker-controlled and therefore a potential injection point.

The Same-Origin Policy (SOP) is the browser's core security mechanism. A page at https://bank.com cannot read the response from a request to https://evil.com. SOP is enforced by the browser, not the server. Every CORS misconfiguration, every CSRF vulnerability, every postMessage attack is fundamentally a bypass of or gap in SOP. Understand this deeply before anything else.

Cookies are the primary session mechanism. They have flags that determine security: HttpOnly prevents JavaScript access (blocks XSS cookie theft), Secure prevents transmission over HTTP, SameSite=Strict/Lax/None controls cross-site sending (CSRF mitigation). A cookie without these flags is a vulnerability waiting to happen. Always check flags in Burp.

Understanding the business side of bug bounty before you find your first bug is essential. The difference between hunters who earn consistently and those who find bugs but get nothing is largely strategy — choosing the right programs, understanding scope, writing reports that get triaged correctly, and building relationships with the right companies.

The major platforms: HackerOne (largest, most enterprise programs, strongest reputation system), Bugcrowd (strong in financial services and technology), Intigriti (strongest in Europe, GDPR-compliant programs), YesWeHack (growing, good French and European programs), Hackenproof (strong crypto and Web3 programs), and Synack (invite-only, vetted, highest average payouts). Start with HackerOne and Bugcrowd — the most programs, the best documentation, the most learning resources.

Bug bounty programs come in two types. Public programs are open to everyone — high competition, more duplicate reports, but excellent for learning. Private programs are invitation-only — lower competition, faster triage, better relationships with security teams, and typically higher payouts. You get invited to private programs by performing well on public ones. Reputation score on HackerOne is the primary invitation criterion.

Burp Suite is the industry-standard tool for web application security testing. The Community Edition (free) gives you everything you need to find real bugs. Every professional bug hunter uses Burp as their primary tool. Learning it deeply is non-negotiable.

Proxy: Intercepts every HTTP/S request between your browser and the target. You can pause, inspect, and modify any request before it reaches the server. This is how you test every parameter, every header, every cookie for injection vulnerabilities. Set Intercept to off for browsing — turn it on only when you want to pause and modify a specific request.

Repeater: Send any intercepted request here and re-send it as many times as you want with modifications. This is where you test payloads — modify the parameter, send, check the response, modify again. You will spend 80% of your time in Repeater.

Intruder (CE limited): Automates payload injection across a parameter. Community Edition rate-limits this heavily but it still works for small wordlists. Use for brute-forcing parameters, fuzzing inputs, and testing for IDOR across a range of IDs.

Decoder: Encode/decode Base64, URL encoding, HTML entities, hex. Attackers and developers both use encoding to transform payloads. Understand what encoding is applied to your input — XSS payloads that get URL-encoded before reaching the DOM don't fire. You need to know when and how encoding is applied.

Extensions (BApp Store — many free): Logger++ (enhanced HTTP history), Retire.js (identifies vulnerable JavaScript libraries), JWT Editor (free — manipulate and attack JWT tokens), Param Miner (discovers hidden parameters — extremely valuable), Turbo Intruder (fast fuzzing, Python-scriptable), Active Scan++ (additional active scanning checks).

The main website of a company (www.company.com) is the most hardened, most tested, most monitored part of their attack surface. The interesting bugs are on subdomains: internal tools exposed to the internet, staging environments with debug features enabled, forgotten microservices with no authentication, acquisition targets running older software. Subdomain enumeration finds these targets.

The ProjectDiscovery toolkit (all free, open-source) is the industry standard for recon automation. subfinder queries certificate transparency logs, DNS datasets, and passive sources to find subdomains without touching the target. amass does active and passive enumeration using dozens of data sources. httpx takes a list of subdomains and probes which ones are alive with an HTTP server. nuclei runs templated checks against live targets — 7,000+ templates covering known CVEs, misconfigurations, and exposure patterns.

Certificate Transparency (CT) logs are one of the most valuable recon sources. Every TLS certificate issued for *.company.com is logged publicly. crt.sh (free) searches CT logs — a single query often reveals subdomains that no passive DNS dataset knows about. Always run crt.sh before touching any other recon tool.

Web applications expose far more than what the UI shows. Hidden endpoints, backup files, admin panels, configuration files, and API documentation live at paths that are not linked from the main navigation but are accessible if you know to look. Content discovery finds them.

ffuf (free) is the fastest directory and parameter fuzzer available. Feed it a wordlist (SecLists — free, 50,000+ wordlists for every purpose) and it will test thousands of paths per second against your target. The key is wordlist selection — a generic wordlist misses framework-specific paths. Use framework-specific wordlists when you know the target stack (WordPress, Laravel, Spring, Django all have dedicated wordlists in SecLists).

JavaScript files are the bug bounty hunter's hidden treasure. Modern web apps move business logic to the frontend — JavaScript files contain API endpoints, authentication tokens (sometimes hardcoded), feature flags that reveal functionality, internal path references, and sometimes actual credentials. Every JavaScript file in scope deserves analysis.

Before touching a target's servers, search engines and OSINT databases have already indexed significant information about it — sometimes including leaked credentials, exposed configuration files, and unintended public resources. This information is available without sending a single request to the target.

Google dorking uses advanced search operators to find specific types of content. The Google Hacking Database (GHDB — free at exploit-db.com/google-hacking-database) contains thousands of dorks that have historically found real vulnerabilities. For bug bounty, the most valuable dorks find: exposed configuration files, login panels, API documentation, error messages with stack traces, and GitHub repositories with credentials.

Shodan (free tier at shodan.io) is a search engine for internet-connected devices. It scans the entire internet continuously and indexes what it finds — open ports, running services, TLS certificates, HTTP response headers. For bug bounty, Shodan reveals: exposed admin panels, services running on non-standard ports, systems with outdated software versions, and infrastructure that was meant to be internal but is internet-accessible.

SQL injection remains one of the highest-paying bug classes because the impact is so severe — a single SQLi vulnerability can expose an entire database including user credentials, payment information, private messages, and administrative data. Modern frameworks make SQLi less common than it was, but it still appears regularly — especially in older applications, custom CMS builds, backend APIs, and search functions.

SQLi exists when user input is concatenated directly into a SQL query without parameterisation. The database cannot distinguish between attacker-supplied SQL syntax and intended application logic. The attacker can manipulate the query structure to extract data, bypass authentication, or in some configurations execute operating system commands.

Detection starts with a single apostrophe: ' in every parameter. A 500 error, a different page, or a database error message confirms the input reaches a SQL query. Then determine injection type: in-band (results visible in response — easiest), blind boolean (no visible output, but behaviour changes based on true/false), blind time-based (inject SLEEP(5) — if response delays, injection works). Type determines your extraction technique.

XSS is the most common paid vulnerability in bug bounty. It occurs when an application includes unescaped user input in its HTML output, allowing attackers to inject JavaScript that executes in victims' browsers. The impact ranges from trivial (self-XSS requiring victim to run their own code) to critical (stored XSS on an admin panel stealing administrator session tokens).

Reflected XSS executes when a victim clicks a crafted link. The payload is in the URL, reflected in the response, and executed. Impact depends on context — in the main app with session cookies accessible, this is High. In a subdomain with no sensitive cookies, this is Medium.

Stored XSS is saved in the database and served to every user who views that content. A stored XSS in a comment field that every admin sees when reviewing moderation is Critical — you can steal admin tokens and achieve account takeover. Stored XSS in an isolated, low-traffic page is lower severity. Always assess who sees the payload.

DOM-based XSS occurs when JavaScript in the page reads attacker-controlled data and writes it to the DOM unsafely. The server never sees the payload — it's purely client-side. DOM XSS requires reading JavaScript source to find vulnerable sinks (innerHTML, document.write, eval, location.href assignments) and sources (location.hash, location.search, postMessage, document.referrer).

Insecure Direct Object Reference (IDOR) is the most consistently paid vulnerability class in bug bounty. It occurs when an application uses a user-controllable reference (an ID, UUID, email, filename) to access objects and does not verify that the requesting user is authorised to access that object. Change user_id=123 to user_id=124 and see another user's data — that is IDOR.

IDORs are often not visible in the main UI. The richest IDOR hunting ground is the API — mobile apps and single-page applications make API calls that expose object references the web UI hides. Always test the API endpoints (find them via JS analysis or Burp traffic) with a different user's session token. A request that works with User A's session but should require User B's token is an IDOR.

SSRF (Server-Side Request Forgery) causes a server to make HTTP requests to attacker-specified destinations. If you can control a URL parameter and the server fetches it, you can redirect requests to internal services (169.254.169.254 for AWS metadata, 10.x.x.x for internal APIs, file:// for local file read). SSRF to the AWS metadata endpoint retrieving IAM credentials is Critical on any cloud application — it exposes the server's cloud credentials.

XXE (XML External Entity Injection) occurs when XML parsers process external entity definitions included in XML input. If an application accepts XML and the parser is configured to process external entities, an attacker can read local files (/etc/passwd, application config files with credentials), perform SSRF (the parser makes external network requests), or in some configurations achieve remote code execution. XXE is less common than XSS or SQLi but consistently pays High to Critical when found.

Path traversal (directory traversal) allows an attacker to access files outside the intended directory by manipulating file path parameters. ../../../../etc/passwd traverses up the directory tree to access the password file. Modern frameworks usually prevent this, but custom file handlers, image processors, and document renderers still have it. The highest-impact version reads application configuration files containing database credentials or API keys.

Information disclosure is underrated by new hunters. Exposed stack traces reveal framework versions, file paths, and sometimes source code. Debug endpoints reveal internal architecture. Backup files (.bak, .old, .orig, ~) contain source code. Version control metadata (.git, .svn) can expose the entire application source. A single .git directory exposed on a production server has led to Critical findings worth $10,000+ because it contained production credentials committed to the repository.

Business logic vulnerabilities are flaws in the design of an application's workflows — not in the underlying code. They cannot be found by automated scanners because scanners do not understand what the application is supposed to do. They require a hunter who understands the business domain and can reason about what should and should not be possible.

Every application has workflows with assumptions built in: you cannot purchase items without paying, you cannot apply a discount code twice, you cannot access step 3 of a checkout without completing steps 1 and 2, a free account cannot access premium features. Business logic vulnerabilities violate these assumptions — and the resulting bugs are often High or Critical because they directly affect the company's revenue, data integrity, or security model.

Authentication is where the highest-severity bugs live because breaking authentication means account takeover — typically a High or Critical finding regardless of what data is accessible. Modern applications use JWTs (JSON Web Tokens) and OAuth for authentication and authorisation. Both have complex specifications with well-documented attack patterns.

A JWT has three parts separated by dots: Header (algorithm and type), Payload (claims — user ID, role, expiry), Signature (verification). The signature prevents tampering — if you modify the payload, the signature becomes invalid and the server should reject the token. JWT vulnerabilities arise when applications implement verification incorrectly. The algorithm confusion attack (alg:none or RS256 to HS256 confusion) is the most consistently paid JWT vulnerability class.

OAuth 2.0 allows users to grant third-party applications access to their account without sharing passwords. Misconfigurations in redirect_uri validation allow attackers to steal authorization codes. Open redirectors in the target application can be chained with OAuth flows to redirect codes to attacker-controlled servers. State parameter absence allows CSRF against the OAuth flow. These chains often result in account takeover without any credentials.

HTTP Request Smuggling exploits ambiguity in how front-end and back-end servers parse HTTP requests — specifically the Content-Length and Transfer-Encoding headers. When two servers disagree on where a request ends, an attacker can "smuggle" a partial request that the front-end does not see but the back-end processes. This can bypass security controls, poison the request queue of other users, and in some configurations achieve cache poisoning or XSS against arbitrary users. Top hunters consistently earn $3,000-$25,000 for smuggling bugs on major programs.

Prototype Pollution is a JavaScript-specific vulnerability where an attacker can modify the Object.prototype — the prototype chain that all JavaScript objects inherit from. By polluting a shared property on Object.prototype, an attacker can override application logic, bypass authentication checks that test for property existence, or in server-side Node.js applications, achieve remote code execution. It is found in applications that merge or parse user-supplied JSON or query parameters without sanitisation.

Modern applications are API-first — the web UI and mobile apps are thin clients that call REST or GraphQL APIs for all data. This means the real application logic, the real authorisation decisions, and the real vulnerabilities are in the API layer, not the HTML pages. Hunters who test APIs find bugs that web-only hunters miss entirely.

The OWASP API Security Top 10 defines the most common API-specific vulnerabilities: Broken Object Level Authorization (API IDOR), Broken Authentication, Excessive Data Exposure, Lack of Resource Rate Limiting, Broken Function Level Authorization, Mass Assignment, Security Misconfiguration, Injection, Improper Asset Management, and Insufficient Logging. Each has distinct testing methodology that differs from traditional web app testing.

Mass Assignment is an API-specific vulnerability worth special attention. When an API endpoint accepts a JSON body and passes it to an ORM (Object Relational Mapper) without filtering, an attacker can add extra fields — including privileged fields like role, is_admin, account_balance — to the request and have them applied to the database object. This is extremely common in Node.js/MongoDB and Ruby on Rails applications.

GraphQL is replacing REST APIs in modern applications and brings its own unique attack surface. Unlike REST (which has predefined endpoints), GraphQL has a single endpoint that accepts flexible queries. This flexibility creates security challenges that many development teams underestimate.

Introspection is GraphQL's built-in schema discovery feature. If enabled in production, it reveals every type, query, mutation, and field the API supports — a complete map of the attack surface. Enable introspection query: {"query":"{__schema{types{name,fields{name}}}}"}. If the server returns schema data, introspection is enabled. Use GraphQL Voyager (free, tool) to visualise the entire schema as a relationship diagram.

Batch queries allow multiple operations in a single HTTP request. If rate limiting is applied per-request rather than per-operation, an attacker can send 1,000 login attempts in a single HTTP request by batching 1,000 queries. This completely bypasses per-request rate limiting and enables brute force attacks that should be impossible.

Most hunters only test web applications. Bug bounty programs with mobile apps in scope have significantly less competition — fewer hunters have the skills, fewer automated tools cover mobile, and mobile apps often have more API exposure than the web version. Adding mobile testing to your skillset immediately reduces duplicate rates on every program that includes Android or iOS apps in scope.

Static analysis — decompile the APK without running it. jadx -d output/ app.apk (jadx — free) decompiles APKs to readable Java. Search the decompiled code for: hardcoded credentials, API keys, internal endpoints, developer backdoors, and insecure cryptography implementations. MobSF (Mobile Security Framework — free) automates static analysis and produces a detailed report covering permissions, hardcoded secrets, insecure API usage, and dangerous Android component configurations.

Dynamic analysis — run the app and intercept its network traffic through Burp. Android apps that use certificate pinning will refuse to connect when Burp's certificate is installed. Bypass certificate pinning using Frida (free) with the Universal Android SSL Pinning Bypass script, or using apk-mitm (free) which patches the APK to disable pinning before installation.

A vulnerability report has two jobs: convince the triage team the bug is real, and convince them it is as severe as you claim. Failing at either means a lower payout, a request for clarification that delays payment, or a rejection. The same underlying vulnerability can be rated anywhere from Informational to Critical depending on how the report frames the impact.

Triage teams receive hundreds of reports per week. They are looking for any reason to downgrade or close reports quickly. A clear, professional, complete report gets processed faster, gets paid at the correct severity, and makes the triager's job easier — which builds goodwill and leads to faster responses on future reports. A vague, incomplete report with a bad PoC gets deprioritised or marked informational.

The most common reason reports get downgraded: weak impact statement. "An attacker could steal cookies" is weak. "An attacker who sends the victim a phishing link can steal their authenticated session cookie, log into their account, access all stored payment methods and order history, and change the account email to lock the victim out — requiring no victim interaction beyond clicking a link" is strong. Always articulate the full attack chain from attacker action to victim impact.

The top 50 researchers on HackerOne collectively earn millions of dollars per year from bug bounty. The median researcher earns almost nothing. The difference is almost entirely strategy, not raw skill. Many technically brilliant hunters earn very little because they spread themselves across too many programs, chase the wrong targets, and do not systematically build their income.

The path to consistent income has three stages: Stage 1 — Build reputation (first 0-20 accepted reports) by focusing on programs with wide scope and fast triage, finding lower-hanging bugs, and demonstrating quality reports that get accepted without pushback. Stage 2 — Get private invitations (20-100 reports) by maintaining a high signal-to-noise ratio, getting recognised for quality, and actively applying to programs that accept applications. Stage 3 — Scale (100+ reports) by focusing exclusively on private programs, building automation that finds vulnerabilities at scale, and developing specialisations that reduce competition.

Top earners do not manually test everything — they automate the routine and focus their manual effort on high-value targets. Automation handles continuous recon, known CVE detection, subdomain monitoring, and low-complexity vulnerability checks. This frees human time for the creative, manual work that finds unique, high-severity bugs that automation cannot find.