Most beginners quit bug bounty somewhere in week two. Not because the bugs are impossible to find, but because the first month turns into installing tools, half-reading other people's writeups, and poking whatever endpoint looks interesting. Thirty days of structured work is enough to avoid that. The plan below is built around recon, because recon decides whether you find anything at all — and it is the one skill that transfers to every program you will ever touch.
Recon is not running one subdomain tool and calling it done. It is building an accurate map of what an organisation exposes, then narrowing that map to the parts nobody has tested properly. Two flavours matter. Passive recon uses public data: certificate transparency logs, DNS records, archived URLs, code repositories. Active recon sends traffic to a target, and that is where you have to be strict about scope.
Read the program's policy before you send a single request. Scope defines what you may touch, which techniques are banned, and what counts as a valid finding. Everything below assumes you are working inside an authorised program.
Aim for boring and repeatable. Fancy setups eat the hours you should spend testing.
subfinder for subdomains, httpx for probing live hosts, ffuf for content discovery, waybackurls or gau for archived URLs, nuclei for templated checks, and your proxy for manual work. Learn these properly instead of installing forty tools you will run once. Practise the loop on a domain you own: enumerate, resolve, probe, screenshot, take notes.
Pick two or three programs, not ten. Look for a wide wildcard scope, a policy written in plain language, and a public disclosure history you can read to understand what that team considers valid. A single-URL scope with vague rules is a poor first program.
Write a scope file for each: in-scope roots, out-of-scope assets, rate limits, banned techniques, anything that earns a bonus. Then start the inventory.
This is the week beginners actually find things, because the interesting bugs are rarely the first ones you meet.
Run the Wayback Machine against each host. Old endpoints that no longer appear in the app often still respond, and they get far less attention than live routes. Start content discovery with a medium wordlist; if a host answers everything with 200, slow down rather than blast it.
Download the main JavaScript bundles for your best hosts, pretty-print them, and search for strings: /api/, /v2/, admin, token, key, secret, internal. Single-page apps often leak their entire route map if you read carefully, and enabled source maps make it trivial. Note every endpoint, then check it manually in the proxy. This step produces fewer results than automated scanning but far better ones, because you are the only person looking at that particular file.
Choose one class for the final four days. Access control is the safest bet for a first finding. Create two accounts on the target, capture every request that carries an identifier, and replay each one with the other account's session. Test both directions: can user A read user B's data, and can user A change it? Document as you go — exact request, response, why it is unexpected, what an attacker gains.
Lead with a clear title, then reproduction steps anyone can follow, then impact. Attach raw requests and responses. Don't inflate severity; explain your reasoning and let the triager decide.
If you cannot explain the impact in two sentences, you probably do not understand the bug yet.
A calm, accurate report on a small bug builds reputation faster than a dramatic claim that collapses during triage.
Only test assets inside the scope of a program that authorises testing. Testing systems without permission can be illegal, and no finding is worth that risk. Never access other people's data, don't run destructive payloads, respect rate limits, and follow any ban on automated scanning. If you stumble onto something sensitive, stop and report it privately through the program's channel. If the legal side is unclear, get advice from a qualified professional before continuing.
Keep the habit, not the plan. Revisit your notes, pick a new asset class on an existing program, and repeat the loop: enumerate, probe, read, test, report. Your first bug is usually dull — a leaked config file, a sloppy CORS header, an order ID you can swap. Submit it anyway. Each report teaches you how the platform and the program's team operate, and that knowledge is what turns thirty days of recon into a long run.
Photo: MART PRODUCTION / Pexels
CVSS turns a vague severity opinion into a defensible number. Here is how the metrics work, how to build a vector,...
A practical roadmap for leaving a salaried IT security role for full-time bug bounty, covering skills, track record,...
A step-by-step build of a Subfinder, httpx and Nuclei recon pipeline — install, script, filter the noise, and...
Notes from the front lines of bug hunting.
