Always-Rejected Reports: The Patterns That Waste Everyone's Time
Cybersecurity
Some report patterns are auto-closed by every program that has been running for more than a year. This is the list, why they get rejected, and what you should hunt for instead if you are tempted to submit one.
By Arjun Raghavan, Security & Systems Lead, BIPI · June 29, 2023 · 8 min read
Why this list matters
Submitting an always-rejected report costs you reputation on the platform. Repeated submissions get researchers throttled or banned. Knowing the list saves your account and the program's time.
Missing security headers
X-XSS-Protection not set, Strict-Transport-Security missing on a redirect, Referrer-Policy too loose. On their own, these are configuration suggestions, not vulnerabilities. Rejected by every mature program.
Self-XSS with no delivery vector
If the only way to trigger the XSS is to paste a payload into your own browser console or your own settings, it is not a bug. Find a delivery vector, then resubmit.
CSRF on logout
Logging out a user is not a security impact most programs care about. Annoying, sure, exploitable, sometimes for cache poisoning. On its own, rejected.
Rate limiting on endpoints with no business impact
Login rate limiting matters. Password reset rate limiting matters. The contact form, the search page, the public catalogue, usually do not. Tie rate limiting to a concrete abuse scenario or skip.
Username enumeration on signup
If the signup flow says the email is taken, that is by design. Combine with an account lockout or a password reset oracle and you might have something, but the enumeration alone is rejected.
Outdated software versions with no proof of exploit
Reporting that nginx version X has known CVEs is not a finding. Reporting that you exploited a specific CVE against the running instance is. Show, do not list.
Tab nabbing and target=_blank without noopener
Modern browsers handle this. Rejected.
Clickjacking on non-sensitive pages
The marketing site framable in an iframe is not a vulnerability. The account deletion page being framable is. Specify the page and the action it would enable.
Reports without proof of concept
If your report says, this endpoint might be vulnerable to SQLi based on the response time, you have homework, not a report. Confirm or skip.
Scanner output dumps
Burp scanner, Nuclei, ZAP, none of them produce reports. They produce hints. Triagers can tell within seconds when they are reading a copy-pasted scanner finding. Always-rejected and reputation-damaging.
Theoretical attacks with no real victim
If your report explains how a sophisticated attacker with a state actor budget might use this to harm someone in a specific edge case, you are writing fiction. Find a real impact path or skip.
DoS via large payloads or compute exhaustion
Most programs explicitly exclude DoS testing. Read the program rules before sending a single oversized request. Some programs do pay for application-layer DoS with a real impact story, but only when it is documented as in scope.
What to hunt for instead
- Business logic flaws that move money, change ownership, or skip checks
- Tool-use IDORs in AI features
- Authorisation bugs in shared resources
- Open redirects on OAuth-anchored domains
- Chains that turn three lows into one critical
Every always-rejected pattern has a real-bug cousin that pays well. Spend the time finding the cousin.
Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.