Top 7 Mistakes New Bug Hunters Make (And How to Avoid Them)

A first bounty feels like it should arrive quickly. You read a few writeups, install a handful of tools, and start poking at a program. Three weeks later you have submitted nothing — or you got a polite "not applicable" and a note about scope. Nearly every hunter goes through this. The ones who stay are rarely the most talented; they just stopped making the same seven mistakes.

Mistake 1: Treating the Scope as a Suggestion

The scope is not paperwork. It is the line between authorized testing and unauthorized access, and it decides whether your finding gets paid or gets you removed from the program. Read the entire policy before you send a single request: in-scope assets, out-of-scope assets, rate limits, banned techniques, whether automated scanners are allowed, and any required header or test account.

Wildcards are the usual trap. A program listing *.example.com may exclude the apex domain, may not cover a product on a different top-level domain, and almost never includes a third-party service the company merely uses. If the policy names an exception, treat it as absolute.

• Save the scope to a local note and re-check it before every session; programs update policies quietly.
• Test only with accounts you own or the ones the program issues. Prove an IDOR with a single request, then stop — do not enumerate.
• If something is unclear, ask through the platform's messaging feature. Guessing is how hunters get banned.

Testing outside an authorized scope can have legal consequences. No finding is worth that risk.

Mistake 2: Skipping Real Recon

If you only test what the homepage links to, you are competing with everyone who did the same thing in ten minutes. Bugs tend to sit in forgotten places: staging subdomains, older API versions, admin panels behind a login, mobile endpoints the web app never calls.

Recon is not one tool run. It is a habit of building an inventory and revisiting it. A workable loop:

1. Enumerate subdomains, then resolve and probe them for live HTTP services.
2. Mine historical data — archived URLs, JavaScript files, DNS records — for endpoints that still respond.
3. Pull the JavaScript bundles and look for API paths, feature flags and hardcoded hostnames.
4. Repeat monthly. New assets appear constantly, and old ones come back from the dead.

Mistake 3: Running Tools You Don't Understand

Every hunter has pasted scanner output into a report and hoped. Triagers spot it immediately, and a trail of false positives follows your username. A tool flags a pattern; it does not prove impact.

Learn the vulnerability class before you automate it. If a scanner reports a possible injection, your job is to confirm the parameter, craft the minimal proof, and explain what data an attacker could actually reach. The same applies to template scanners, directory brute-forcers and anything else that produces a wall of URLs. Automate the boring parts — enumeration, fuzzing, diffing — and keep your judgement for verification.

Mistake 4: Ignoring Business Logic and Access Control

Reflected XSS on a marketing page is heavily hunted and often pays little. Broken access control and logic flaws are the opposite: quieter, hard to automate, and frequently rated high or critical.

These bugs live in the flow, not in the payload. Create two accounts, place a real object in one, and check whether the other can read or modify it by changing an identifier. Then attack the process itself:

• Skip a step: call the final endpoint of a checkout or onboarding flow without completing the earlier ones.
• Replay a request out of order, or twice at the same moment, and see whether a limit, balance or coupon is applied twice.
• Change values the client controls but should not: price, quantity, role, discount, tenant ID.
• Test the unhappy paths — cancelled orders, expired invites, downgraded plans — where checks are often missing.

A useful rule: if a feature has a rule a human wrote ("only managers can approve this"), there is likely a bug where the code forgot to enforce it.

Mistake 5: Submitting Before Verifying

Two problems kill more reports than anything else: the bug does not reproduce, and the bug has no impact. Before you write anything, reproduce it in a clean session, on a second account, or in a different browser. Then ask what an attacker gains. If the honest answer is "not much", it belongs in your notes, not in the program's queue.

Reports commonly closed as informational include missing security headers on their own, self-XSS, version disclosure with no working exploit, and email configuration issues with no demonstrated abuse. They are not always wrong; they are simply not vulnerabilities by themselves. Impact is the product you are selling.

Mistake 6: Writing Reports a Triager Has to Decode

The triager is your reader and your only advocate inside the program. Make their job trivial. A report that takes four passes to understand gets triaged last, or gets misread.

• Title: vulnerability type plus the exact asset — "IDOR in invoice PDF endpoint allows reading other tenants' invoices".
• Summary: three sentences on what you found and why it matters.
• Steps: numbered and copy-pasteable, with no missing requests or session details.
• Impact: who is affected, what they lose, what an attacker can do next.
• Evidence: requests and responses, plus a short screen recording, redacted only where necessary.
• Remediation: one or two concrete suggestions, not a lecture.

Check the program's requirements too — rating system, mandatory fields, language. Matching the format they asked for is part of the work.

Mistake 7: Quitting Before the Curve Turns

Bug bounty pays out skill with a delay. The first weeks are mostly reading, mapping and closing dead ends. Hunters who quit usually did it alone, jumped between ten programs, and measured themselves by payout instead of progress.

Pick two or three programs and learn them properly: their stack, their features, their history of disclosed reports. Keep notes on every dead end so you do not repeat it. Track hours spent and techniques learned rather than money earned in month one, and take breaks — staring at the same endpoint for six hours produces worse thinking than walking away for twenty minutes.

A Routine That Beats Luck

None of this needs rare talent. It needs a routine: read the scope twice, build an asset inventory before testing, verify manually before reporting, and write every report for a reader who is short on time. Do that for a few months and you will overtake most of the hunters who started beside you. The bugs are there. The discipline is what finds them.

Photo: geralt / Pixabay