Evidence Guidelines for Hackrate Vulnerability Reports

Evidence is the foundation of a credible vulnerability report. No matter how well-written your description is, a finding without proof is difficult for a triage team to verify — and a finding that cannot be verified is far more likely to be rejected, deprioritized, or delayed. Strong evidence makes your report reproducible by an independent reviewer from scratch, which is exactly what the triage team needs to confirm your finding and move it toward acceptance. This page covers what types of evidence are accepted, how to upload files, what makes evidence compelling, and how to handle sensitive data responsibly.

---

​

Why evidence is required

The pre-validation check that runs before every report submission requires at least one evidence file. If no evidence is attached, the form will not allow submission. This is intentional — it encourages researchers to document their work before filing, rather than submitting speculative reports and adding evidence later. Beyond passing validation, good evidence:

• Speeds up triage. A clear screenshot or screen recording can confirm a finding in seconds. A text-only report may take many back-and-forth comment rounds to verify.
• Prevents duplicate disputes. Timestamped evidence establishes when you found the vulnerability.
• Supports bounty decisions. Reward amounts are often finalized after the impact is confirmed, and strong evidence directly supports a higher severity assessment.
• Demonstrates professionalism. Well-documented reports build your reputation as a researcher the program team can trust.

---

​

Accepted evidence types

---

​

Accepted file formats and size limits

The evidence uploader accepts the following file types: Maximum file size: 150 MB per file.

---

​

How to upload evidence

​

During report creation

​

After submission

You can add additional evidence to an existing report from the report’s detail page at any time while the report is open:

1. Navigate to My Reports and open the relevant report.
2. Scroll to the Upload new evidence panel on the right side.
3. Drop or select a single file. (Evidence is added one file at a time after submission.)
4. Click Upload to finalize. A comment is automatically added to the report’s timeline noting the new upload.

---

​

What makes evidence compelling

Not all evidence is equal. Triagers review dozens of reports — clear, well-organized evidence is noticed and appreciated.

For screenshots

• Show the full browser window including the URL bar so the endpoint is clearly visible
• If demonstrating XSS or injection, include both the payload in the input and the proof of execution (alert box, exfiltrated data, reflected content)
• For IDOR or access control issues, show the account context (logged in as User A) and the unauthorized access (data belonging to User B)
• Annotate with arrows, boxes, or highlights to draw attention to the key part of the image
• Use a consistent naming convention: 01-login-page.png, 02-payload-injected.png, 03-xss-fired.png

For screen recordings

• Keep recordings short and focused — under 3 minutes if possible
• Narrate or annotate key steps in the recording itself (captions, on-screen text)
• Start from a clean, unauthenticated (or freshly authenticated) state to show the full attack chain
• Include a brief setup section showing that the vulnerability is not already known/pre-configured

For HTTP request/response files

• Export the full request including all headers, not just the body
• Include the complete server response — status code, headers, and body
• Redact your own authentication tokens from evidence if not needed for context (replace with [REDACTED])
• For multi-step exploits, include the full sequence in order with clear labels

For PoC code

• Include comments explaining what each section does
• Document prerequisites (target URL, required session tokens, environment setup)
• Keep it minimal — a 20-line PoC is more trusted than a 2,000-line framework
• Test your PoC before including it to verify it actually works against the target

---

​

Handling sensitive data in evidence

When you find a vulnerability that exposes real user data, you face a responsibility to minimize the harm caused by your own research. Follow these practices:

• Use your own test accounts. When demonstrating data access, use accounts you control. If you must demonstrate cross-account access, use a second test account you own rather than accessing real user data.
• Blur or redact real data in screenshots. If real data is visible in a screenshot, blur it before uploading. The presence of the data field is usually enough — the actual values rarely need to be readable.
• For mass data exposure, demonstrate scope without extracting. A screenshot showing the first row of a database dump with the rest blurred, combined with a clear description of the structure, is sufficient. You do not need to include hundreds of rows.
• Delete local copies. Once uploaded to your report, delete any locally stored copies of data that contains real user information.

Responsible handling of sensitive data is part of the ethical standards all Hackrate researchers are expected to uphold.

---

​

File validation

After you upload a file, it goes through an automated validation process. Each file shows one of three states in your report: If a file shows Invalid, upload a replacement before submitting or following up with the triage team. Triagers cannot access invalid files.

---

​

Common evidence mistakes to avoid