Duplicates, N/A and informative: why reports get closed and how to avoid it
Most hunters see many closed reports. Understanding why they happen is the fastest way to get better results.
Almost every hunter gets reports closed without a reward. Knowing the common reasons helps you avoid wasted effort and improve your hit rate.
The common outcomes
Duplicate. Someone reported the same issue earlier. The first valid report usually gets the reward. Duplicates are the most frequent disappointment on popular programs.
Informative. The report is true, but the issue has low or no security impact by the program's standards (for example, a missing header with no exploit path). It is noted, not rewarded.
Not applicable (N/A). The report does not describe a security issue, is a misunderstanding, is not reproducible, or the behaviour is intended.
Out of scope. The asset or issue type is excluded by the policy (for example, a third-party service, social engineering, rate limiting, or self-XSS).
Resolved / triaged / accepted. The issue is valid and is being fixed or rewarded.
Why duplicates happen, and how to reduce them
- Many researchers run the same tools and checklists on the same targets, so shallow bugs are found within hours.
- Fresh assets are tested fastest.
To reduce duplicates:
- Go deeper, not wider. Learn one application thoroughly: its roles, workflows and edge cases. Authorization and business-logic issues need understanding and are less likely to overlap.
- Test new features and recent changes. Watch release notes, changelogs and new scope additions.
- Chain small issues into a clearer impact.
- Check the program's disclosed reports and known issues list before testing an area.
- Be quick on new scope, but still careful and in-bounds.
- Pick less crowded programs and private invites when possible.
Avoiding informative and N/A
- Prove impact. Ask yourself: what can an attacker really do, and to whom? If you cannot answer, do not submit.
- Read the policy's exclusions (commonly listed: missing best-practice headers, clickjacking on non-sensitive pages, rate limiting, verbose errors, self-XSS, software version disclosure).
- Verify tool findings by hand. Scanner results are leads, not reports.
- Reproduce twice from a fresh session before submitting.
- Understand the intended behaviour. A feature can look odd but be by design; read the documentation.
Learning from every closure
- Read the triager's explanation carefully.
- Keep a log of each report, the outcome and the lesson.
- Study disclosed reports on the same program to see what was accepted.
- Ask for clarification politely if the reason is unclear. Do not argue repeatedly or pressure the team.
Keep your reputation healthy
Many platforms track signal: the share of your reports that are valid. A stream of low-quality or duplicate reports lowers it and can reduce access to private programs. Quality over quantity.
Mindset
A closed report is data. Hunters who improve are the ones who analyse their misses, widen their skills (for example, API testing, authentication flows, cloud misconfigurations) and keep a steady schedule.
Takeaway: duplicates, informative and N/A closures are normal. Reduce them by going deep on one target, proving real impact, reading exclusions and learning from each result.
Bug Bounty series, Part 1 (getting started): 4 of 4. Previous: How to write a bug bounty report that gets triaged fast.
