False positives in bug bounty: how to reduce them without rejecting valid reports
By Kike Gandia · Co-Founder & CEO, OSCP
A false positive in a bug bounty programme is a report that describes behaviour that looks like a vulnerability but is not: intended system behaviour, researcher environment misconfiguration, or theoretical vulnerabilities with no practical impact in your environment. Handling them poorly — rejecting without technical arguments or ignoring without a response — is one of the fastest ways to destroy your programme's reputation.
Why false positives are inevitable in any programme
Security researchers work with limited information about your environment. They do not know your compensating controls, your internal configuration or the business context behind each design decision. It is reasonable for them to report things that from the inside do not look like vulnerabilities.
The most common categories of false positives:
• Intended behaviour interpreted as a vulnerability (aggressive rate limiting, error messages without sensitive data).
• Vulnerabilities that require impossible conditions in your environment (physical access, very high privileges).
• Out-of-scope findings reported due to unfamiliarity with the rules.
• Strict security configurations that look like flaws from the outside.
How to respond to a false positive without damaging the researcher relationship
A response to a false positive must meet three criteria: be technically sound, be fast and be respectful.
Recommended structure:
1. Thank the researcher for their time.
2. Explain technically why it is not a valid vulnerability in your environment.
3. If it is intended behaviour, explain the security rationale behind it.
4. If it is out of scope, point to exactly which part of the rules excludes it.
5. Invite the researcher to keep participating.
What you should never do: reject without a technical explanation. 'Not valid' without context is the response that makes the best researchers leave your programme for good.
How to reduce the false positive rate by programme design
Many false positives are the result of a poorly defined scope or ambiguous rules. Preventive improvements:
- Specific and detailed scope: exact list of domains, URLs and APIs in scope. Avoid generic wording.
- Examples of out-of-scope vulnerabilities: if there are types of findings you frequently receive but are not valid, list them explicitly.
- Programme FAQ: frequently asked questions about what counts as valid.
- Test environment: if you can offer a staging environment to researchers, you drastically reduce reports based on production behaviour.
- Public security documentation: publishing your security header policy or configurations reduces reports about 'missing security headers' that are actually correctly configured.
The real cost of false positives in your programme
Every false positive has a direct operational cost: the analyst's time to review it and the time it takes to communicate the rejection. In programmes with a high false positive rate (>60%), the team may be spending more time managing invalid reports than working on real vulnerabilities.
The indirect cost is greater: quality researchers keep a mental record of programmes where their reports receive poor responses. If your rejection rate is high but the explanations are poor, the best researchers will move to programmes that treat them better.
FAQ
What is a normal false positive rate in a bug bounty?
It depends on the sector and programme maturity. In well-managed programmes with a clear scope, the false positive rate is usually between 30% and 50% of total reports received. In new programmes or those with an ambiguous scope, it can exceed 70%. The goal is not zero false positives, but to manage them well and reduce them progressively.
How do I tell a false positive from a vulnerability I don't understand?
If you are unsure whether a report is a false positive, the safe response is to reproduce the attack. If you cannot reproduce it with the researcher's steps, ask for more information before rejecting it. Rejecting without having attempted to reproduce the finding is a common mistake that damages the programme's reputation.
Can I mark a report as invalid without paying if I cannot reproduce it?
Yes, but carefully. If the researcher provides clear evidence (screenshots, real tokens, server response data) and you cannot reproduce it, the right thing to do is to communicate this and request more detailed steps. Only if after a reasoned exchange it is still not reproducible is it justified to close it as invalid.