Overview
Not every observation is a real vulnerability; recognizing false positives before reporting protects credibility. This lesson covers false positives in validation.
Learning objectives
- Define false positives in the bug bounty context.
- Explain distinguishing real findings from false positives.
- Connect false-positive filtering to credibility and reward.
Core concept
A false positive is an observation that appears to be a vulnerability but is not genuinely exploitable or impactful — for example, a suspected XSS where the input is actually encoded or CSP-blocked, a "SQLi" that's just a reflected error, or a supposed access issue that's actually authorized behavior. Validation must filter out false positives before reporting: only genuinely reproducible, exploitable, impactful findings should be submitted. Reporting false positives wastes triage time, harms the researcher's reputation, and may count against them — so distinguishing real findings from false positives is essential.
How it works
For each candidate, the researcher critically checks whether it is genuinely a vulnerability: does it actually reproduce and have real impact, or is there a benign explanation (encoding/CSP blocking a suspected XSS, a reflected error that isn't injectable, authorized behavior mistaken for an access flaw, a scanner artifact)? They validate — confirming exploitability and impact safely — and discard anything that turns out benign. This mirrors the validation/false-positive discipline from the ethical-hacking and web-assessment modules. Only findings that survive this scrutiny (real, reproducible, impactful) are reported. Filtering false positives keeps submissions credible and triage-efficient.
Practical example
The researcher has a candidate XSS (input reflected in a response). Before reporting, they check for a false positive: is the input actually encoded (harmless) or blocked by CSP? Testing safely, they find the input is HTML-encoded — so it does not execute. It's a false positive, and they discard it rather than reporting. Had they reported it, triage would reject it and their reputation would suffer. Recognizing the false positive kept their submissions credible.
Cybersecurity relevance
Filtering false positives is essential to credibility and standing in bug bounty: programs track report quality, and submitting false positives wastes triage time and harms the researcher's reputation (and signal/stats on platforms). It mirrors the validation discipline across the paths — validate before reporting. Distinguishing real, exploitable, impactful findings from benign observations (encoded input, reflected errors, authorized behavior, scanner artifacts) ensures only credible findings are submitted. This protects the researcher and the program relationship and is a core validation skill, especially given automated tools' tendency to produce false positives.
Common mistakes
- Reporting candidates without validating they're genuinely exploitable/impactful.
- Mistaking benign behavior (encoded input, reflected errors, authorized access) for vulnerabilities.
- Submitting scanner output without confirming real findings.
Key takeaways
- A false positive is an apparent vulnerability that isn't genuinely exploitable/impactful (e.g. encoded/CSP-blocked "XSS", reflected-error "SQLi", authorized behavior).
- Validate before reporting — confirm real exploitability and impact, and discard benign candidates.
- Filtering false positives protects credibility, standing, and triage efficiency; only real, reproducible, impactful findings should be submitted (mirroring the validation discipline).
Check your understanding
- Give an example of a false positive and how you'd recognize it.
- Why does filtering false positives matter for a researcher's credibility and standing?