HackerOne

🔹 Getting Started (Setup)

🔧 Testing Requirements

Required Setup and Identification

Set a custom HTTP header in all testing traffic. Include the header you used in your vulnerability report so HackerOne can identify your activity and deconflict it from other testing.

Testing Rules and Policies

🔒 Handling Sensitive Information

All vulnerability reports and related data must be treated as sensitive and handled accordingly.

Failure to comply with these testing requirements may result in your submission being deemed ineligible for a bounty.

Program Scope and Assets

In Scope

Issues affecting assets under HackerOne's control are in scope. This includes:

• Vulnerabilities affecting self-hosted assets
• Incorrect asset configurations
• Missing or incomplete security patches
• Other security issues within HackerOne's control

Out of Scope

Third-party assets outside HackerOne's control are not authorized for testing because HackerOne cannot grant permission to test infrastructure it does not host or operate.

Reports affecting third-party assets will generally be closed as Informative. In exceptional cases, HackerOne may award a discretionary bonus when a report demonstrates meaningful value to HackerOne's security posture.

🧪 Testing Resources and References

General Guidelines

Sandbox Usage

Whenever possible, perform testing within your own HackerOne sandbox organizations.

You may create a sandbox program using HackerOne's program creation workflow and select any available product edition. This provides access to nearly all HackerOne features. Researchers may create up to 30 sandbox programs.

Live Environment Testing

When testing in a live environment, you may only test against the approved HackerOne test programs listed in this document.

Approved Reports for Proofs of Concept

You may only use the following approved vulnerability reports when demonstrating a proof of concept (PoC).

⚠️ Source Restrictions (Bounty Eligibility)

Only the approved proof-of-concept reports listed above may be used when demonstrating a vulnerability.

Do not use:

• Reports from any other HackerOne program
• Reports from private customer programs
• Reports from any non-HackerOne source

⚠️⚠️⚠️WARNING⚠️⚠️⚠️ Using an unapproved report makes your submission ineligible for a bounty.

If your submission relies on testing performed using:

• another HackerOne program, account, or report, not approved for testing,
• a customer program, or
• any non-HackerOne source,

It may result in your submission being deemed ineligible for a bounty.

Using multiple approved proof-of-concept reports to demonstrate the same issue does not increase the severity or reward of a finding.

Scope Restrictions

Do not access or test:

• Customer programs
• Customer environments
• Customer data

Data Handling

If you inadvertently obtain sensitive information during testing:

1. Stop testing immediately.
2. Contact HackerOne.
3. Delete the information from all local and stored systems.

HackerOne may request confirmation that the data has been deleted. HackerOne may also request the usernames, IP addresses, or other identifiers used during testing to assess potential impact.

📋 Program State Testing

Program States

HackerOne supports six program states that are relevant to testing:

• Sandbox
• Invite-only
• Public
• External program
• External program + Sandbox
• External program + Invite-only

A valid vulnerability exists when there is an unauthorized or security-relevant difference between the behavior of Sandbox and Invite-only programs.

It is not a vulnerability if a researcher cannot distinguish a Sandbox program from an Invite-only program.

Use the following approved programs for testing.

Test Programs

Test Objects for Proofs of Concept

You may use the following object identifiers when creating proofs of concept on hackerone.com.

🚫 Denial-of-Service (DoS) Policy

Dos Rules Overview

DoS Reward

Eligible Denial of Service (DoS) findings are capped at the Medium severity bounty rate for the affected asset.

Reports that include prohibited testing methods or actions are not eligible for a reward.

DoS Eligibility

To qualify for a DoS reward, a finding must demonstrate measurable degradation of HackerOne's servers or infrastructure, such as:

• Increased response times
• Service unavailability
• Resource exhaustion affecting HackerOne systems

DoS Testing Guidelines

✅ DoS Allowed

• Single-user, realistic actions only
• Begin gradually with one or two requests
• Send testing traffic from a single source IP
• Validate observed impact from a separate IP
• Stop immediately once service degradation is detected

❌ DoS Prohibited

• Distributed denial-of-service (DDoS) attacks
• Testing from multiple attacking IPs
• Automated tools, scripts, or bots
• Resource-exhaustion attacks
• Data corruption or manipulation
• Actions that compromise data integrity