Two researchers find the same IDOR on the same afternoon. One report gets triaged and paid inside a day. The other comes back as Duplicate, Informative, or Needs More Info, and its author spends a week arguing in the comments. The bug was identical. The submission wasn't.
Most rejections have little to do with the quality of the finding. They come from things that were easy to check and never got checked: a subdomain that sat outside scope, a proof of concept that only worked because of a proxy rule, an issue disclosed three months earlier by someone faster. What follows is the verification pass worth running before every submit, whether it's your first report or your five-hundredth.
Open the program page and read it again. Not from memory — scope changes, and programs quietly remove assets, add wildcards, or move a service to a third-party host that no longer qualifies. Check the exact asset you tested against the exact text: *.example.com is not the same as example.com, and a marketing page on a separate domain is usually out of scope even when it looks like part of the product.
Then re-read the testing rules. Many programs restrict you to accounts you own, forbid bulk data access, and ask you to stop the moment you reach another user's data. Proving an authorization flaw by opening a single record is normally fine; pulling a thousand rows to build a chart is not, and it can turn a valid bug into a violation. Note the disclosure terms too. If the program requires coordinated disclosure, your blog post is part of the risk calculation.
Your first successful exploit is the least trustworthy one. You were running extensions, a proxy with match-and-replace rules, and a session that has been alive for two hours. None of that is the application. Reproduce the bug in a clean browser profile, ideally on a second account, and then again with a raw curl command. If it only works when your proxy injects a header, you found a problem in your own tooling.
Confirm the authorization boundary, not just the behavior. "The number in the URL changes" is not a bug. "User A can read user B's invoice, here is A's session and B's document ID" is. Along the way, rule out the classics:
If the issue is intermittent, say so and describe the conditions. A bug that fires one time in five is still a bug, but it needs the trigger documented or the triager will mark it as unreproducible and move on.
A report a triager can't reproduce isn't a report. It's a conversation.
Search the platform's disclosed reports and public hacktivity for the endpoint, the parameter, and the vulnerability class. Check the program's known-issues list and its changelog — a bug you found this morning may have been patched last night, and your browser was serving a cached response. Spend five minutes on a search engine with the exact parameter name; you will be surprised how often a write-up already exists.
If your finding is a duplicate of a disclosed report, that isn't automatically the end. Ask what your version adds: a wider scope, a second role that can trigger it, an escalation the original missed. Then state that difference in the first two lines, so a triager reading forty reports can see why yours deserves a second look rather than a quick copy-paste closure.
Describe what an attacker actually gains, with the account and effort required. "An attacker with a free account can read any customer's invoices by changing a single ID; invoices include billing address and the last four digits of the card on file." That sentence does more work than three paragraphs of hedged speculation. Keep the preconditions visible — no authentication required, victim interaction needed, admin role required — because severity depends on them, not on the label you choose.
If you have five low-severity findings and one serious one, submit the serious one on its own. Mixed reports get triaged by their weakest element, and a real vulnerability can disappear inside a list of missing headers. If you must chain issues to demonstrate impact, explain each link as a numbered step so the chain is easy to follow and easy to verify.
Attach raw HTTP requests and responses with session cookies redacted. Take screenshots with the URL visible, and record a short screen capture for anything that needs more than three steps. Include the browser and version, the account type, and timestamps with a timezone. Redact tokens, secrets, and third-party personal data, but don't black out so much that the vulnerability becomes invisible. And attach files directly to the report — temporary file-sharing links expire before some triage queues get to them.
Before you submit, read your own report as though you were a triager with fifty items waiting and no context on your target. If a step assumes knowledge you had but didn't write down, fix it. If the title buries the vulnerability in a sentence, rewrite it. Then sleep on it for an hour if the bug isn't time-sensitive — the mistakes you catch on the second read are the ones that would have cost you a duplicate or a week of clarification. When a triager does ask for more information, answer with evidence rather than argument, and keep your notes on the reproduction path. They make the retest simple, and they make the next report faster.
Photo: RDNE Stock project / 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.
