Synthèse
We’re raising the bar on what we consider a complete submission. Going forward, reports will be evaluated more strictly against these criteria: A working proof of concept with demonstrated security impact. Show us the impact, don’t just describe it. What could an attacker actually achieve? We need a working proof of concept that demonstrates real exploitation and concrete security impact. Show us the boundary that can be crossed, not just that one theoretically exists. If your report says “this
We’re raising the bar on what we consider a complete submission. Going forward, reports will be evaluated more strictly against these criteria: A working proof of concept with demonstrated security impact. Show us the impact, don’t just describe it. What could an attacker actually achieve? We need a working proof of concept that demonstrates real exploitation and concrete security impact.
Show us the boundary that can be crossed, not just that one theoretically exists. If your report says “this could lead to…” but doesn’t show that it does, it’s incomplete. Awareness of scope and ineligible findings. Before submitting, review our scope and ineligible findings list. Reports covering known ineligible categories (DMARC/SPF/DKIM configuration, user enumeration, missing security headers without a demonstrated attack path, and others) will be closed as Not Applicable, which may impact your HackerOne Signal and reputation.
Validation before submission. No matter what tools you use (scanners, static analysis, AI assistants), you need to validate the output before submitting. A false positive that’s been manually reviewed is caught before it wastes anyone’s time. One that hasn’t is just noise.
Source originale
bounty.github.com
CORTEX