Platform standards set expectations for both program owners and hackers when assessing the reward for a report. Programs should start with a rating system such as CVSS for report assessments, but also consider extra "bumps" for discrepancies between rating scores and actual business impact. This ensures a more accurate and value-based vulnerability evaluation.
These platform standards serve as direction for customers to help provide consistency, fairness, and, above all, the best results possible for all participants on the platform.
We do not encourage programs to deviate from our Platform Standards. If you must deviate, clearly document the exceptions and provide a detailed rationale on your policy page. These documented exceptions will take precedence over our Platform Standards. Deviations without clear justification may lower hacker interest in your program.
Platform Standards
Platform standards are opt-in by default, but you can opt out through your settings page. These standards are displayed on the Security Page.
Issue | Standard | Example |
Severity Rating for Insecure Direct Object References (IDORs) with Unpredictable IDs Effective April 2nd, 2024 | IDORs with unpredictable IDs should be viewed as valid vulnerabilities as there are often ways to obtain an "unpredictable ID." The severity rating should be determined by considering both the ID unpredictability and the method by which the IDs can be obtained. However, the CVSS calculation should include setting 'Attack Complexity' to 'High' unless the report demonstrates that the attack complexity is lower due to how an unpredictable ID is obtained.
CVSS Attack Complexity (AC):
Risk Acceptance Considerations:
Program Decision on Remediation: It is important to note that the severity calculation is separate from a program's final decision on risk treatment. A program may, based on its own internal risk assessment and business context, decide to formally accept the risk of any UUID-based IDOR vulnerability and not intend to remediate the finding, regardless of the calculated severity. | An IDOR is identified, but it requires knowledge of a 16-character-long alphanumeric string. The program should calculate the severity with 'AC:H'. |
Bounty Standards for Multiple Reports Highlighting Systemic Issues Effective April 2, 2024 | When multiple reports identify a systemic issue (i.e. the same vulnerability class across similar endpoints or functionalities), compensation should reflect the value provided, not simply the number of reports submitted.
If a Program receives multiple reports of the same vulnerability class on similar endpoints, it should pay for the value received.
Assessment Criteria: High / Unique Value: A report provides significant additional value if it:
Diminishing / Duplicate Value: A report provides less (or no) additional value if:
Compensation Guidelines: Initial Discovery: Fully reward the first distinct report(s) that effectively demonstrate the systemic issue and its pattern (e.g., typically the first 3 unique submissions establishing the systemic issue).
Subsequent Findings: For additional reports on the same systemic issue:
Multiple Contributor Scenarios: When multiple hackers contribute to identifying a systemic issue, distribute bounties equitably based on:
This value is determined by factors like how the application is coded, whether a single change can resolve the issue and the likelihood that fixing one reported bug will also solve the others. However, reports that alert a program to a systemic issue across its assets should be considered for a discretionary bonus.
Practically, the platform standard is to fully reward the first three reports that point to a systemic issue, followed by a one-time discretionary bonus for any additional findings. In cases where multiple hackers contribute to identifying a systemic issue, efforts should be made to distribute the bounty equitably based on the sequence and impact of each contribution in recognizing the systemic flaw. | A program receives four IDOR reports from a hacker on the same `/admin` endpoint, where each report represents a vulnerable parameter, and a unique code change (different line of code) is required to resolve the issue for each parameter. The affected web app is large with many more parameters, but the hacker worked to find the four places missing protection. Therefore, the issue is not systemic. The program awards each of the four unique reports according to the bounty table.
In contrast, a program receives seven IDOR reports from a hacker for a small web app. The systemic nature of the issue is evident, as it affects a significant portion of the available parameters. The program awards each of the first three unique reports according to the bounty table and applies a discretionary bonus for the remainder. |
Bounty Standards for Bug Chains
Effective April 2nd, 2024 | Often multiple vulnerabilities will be used in a single report to demonstrate a more significant security issue. These reports should be evaluated by their overall impact and paid accordingly. Consider the overall impact when evaluating a report with a known or out-of-scope bug used in a chain. Hackers should disclose all vulnerabilities promptly. Stockpiling vulnerabilities to build exploit chains increases risk unacceptably. Programs should monitor for distinct reports that comprise a serious vulnerability chain and issue bonuses as appropriate. | An SSRF (Server-Side Request Forgery) vulnerability is reported as part of a chain with a known Open Redirect issue. Although the SSRF vulnerability may not be independently exploitable without the open redirect, the existence of the open redirect amplifies the impact of the SSRF. In such cases, the initial report of the open redirect should be re-evaluated and reprioritized in light of the new SSRF finding. The bounty payout should then be based on the severity of the SSRF vulnerability, recognizing its enhanced risk. While a separate bounty is not required for the previously known open redirect report, any top-tier program will go back and award the report because the value is now proven. |
Severity Rating for Vulnerable Network Connection in Client Applications Effective April 2nd, 2024 | Client applications will often have protective measures to ensure traffic from the application is encrypted. However, hackers may discover vulnerabilities that would allow an attacker to bypass these protections, and these bypasses will require being on the same network as a victim. This is referred to as an Adversary In The Middle (AITM) attack. Programs should accept and prioritize fixing these issues. | If a report requires an attacker to disable Certificate Pinning in an application, then that is not a valid vulnerability. However, if a hacker identifies that a specific request within an application is not correctly validating certificate authorities or hostnames in a way that would allow an attacker to decrypt or tamper with communications, that should be considered a valid vulnerability. In most cases, the following CVSS score should be applied, leading to an overall severity of High: CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N |
Responsible Disclosure Process for Third-Party Component Vulnerabilities Updated: February 26, 2024 | Novel vulnerabilities or widespread misconfigurations must be reported to the component owner before being reported elsewhere. Hackers should not disclose details about unpatched vulnerabilities unless coordinated with the component owner. In the event of a disagreement regarding the coordination of vulnerability details between a component owner and the hacker, HackerOne will endeavor to assist in determining the best path for internet safety. | If a hacker discovers a zero-day vulnerability in a third-party component (e.g. ImageMagick), they should report it to the component owner first. Only share the vulnerability with programs upon public awareness of the exploit details, patch availability, or coordination with the component owner or HackerOne. |
Severity Rating for Leakage of Sensitive Personally Identifiable Information [PII] Updated: February 26, 2024 | If the vulnerability disclosed in a report enables an unprivileged attacker to directly access sensitive Personally Identifiable Information (PII) for multiple users, and the exploit that could be applied to a substantial portion of the user base via the internet, the severity rating should be considered Critical.
Sensitive PII includes but is not limited to:
In such cases, the severity should not solely rely on the Common Vulnerability Scoring System (CVSS) as serious scenarios involving the leakage of sensitive information may not be fully captured by CVSS metrics. As soon as a vulnerability exposing sensitive PII is found, testing must stop and the issue should be reported. To help evaluate the sensitivity of a given piece of PII Programs can review Section 3 of NIST SP 800-122 | If a hacker identifies a vulnerability that directly leads to a leak of passport numbers for more than one user of a given application, then the vulnerability should be rated at the critical severity level.
Conversely, a lower severity rating may be appropriate if the leaked information is limited to non-sensitive details, such as a first name. |
Severity Rating for Vulnerabilities Involving a Self-Sign-Up Flow | If self-sign-up is possible, and no other privileges are required, set the Privileges Required metric to None. | If a hacker finds a bug in an application that requires them to sign up and create their own credentials and does not require elevated privileges beyond that, then the CVSS calculation should include PR:N. |
Third-party Components: For Programs Consuming the Component | Third-party components and configurations are effectively part of an asset owner’s application because they have chosen to build the application that way. Programs should pay a reward if they have received value from a report about a vulnerability in a third-party component. This includes if an asset owner has changed a configuration or applied a patch outside of a regular schedule because of the report. | A report is submitted to a program detailing a critical vulnerability in an internet-exposed Content Management System the asset owner has deployed. The normal patching schedule would have resolved the issue in a month, but the report shows that the issue is very serious so the asset owners patch in a few days. The Program should reward for a critical issue because they may have just avoided a breach. |
|
|
|
Exemplary Standards
These are additional optional standards that programs can opt into. If a program chooses to adopt the exemplary standards, a dedicated block listing them will appear on the security page.
Bounty Awards for Discovered Leaked Credentials
Effective April 2nd, 2024 | In alignment with best practices, programs should pay for valid leaked credentials a hacker finds that the program did not already know about and that would not have come up immediately in monitoring solutions. A report should always be awarded if it drives or accelerates action. Hackers should submit the leaked credentials to the program and should NOT test their validity beyond authenticating and then immediately deauthenticating - without exercising any functionality. Hackers must always include the source of where they found a leak, and programs should pay per source of a leak. Hackers should not purchase credentials from a source that obtained them illegally, and programs should not pay for reports with purchased credentials. This is to avoid funding criminal activities. The severity should be based on the type of access a given leaked credential would grant an attacker, meaning administrative-type credentials should often be considered “Critical” issues especially when resulting in access to mass PII. | A hacker uncovers a new code paste that includes administrative credentials for a user in the Program’s organization. In the report, the hacker includes where they found the credentials. The program reviews the report, verifies that the credentials are legitimate, and confirms that their monitoring tools had not yet flagged the leak. The program rotates the leaked credential immediately and pays the hacker for the report at the Critical severity tier. |
Core Ineligible Findings
Please see our document on core ineligible findings, here.
Core Clarifications
Clarification on Using the Availability Metric for Data Deletion Vulnerabilities | The ability to delete the data in an application does not impact the Availability metric in a CVSS score. | If a vulnerability enables an attacker to delete application data, but the application is still operational, then Integrity should be set in line with the scope and scale of the deletion and Availability set to None. This matches the explicit guidance in the CVSS 3.1 release notes. |
Evaluation and Payment for Bypass of a Resolved Report Effective April 2nd, 2024 | If a hacker finds a bypass of a vulnerability report that was fixed by the customer and set in the “Resolved” state, that should be considered a new vulnerability report, distinct from the one that is in the “Resolved” state. Hackers should disclose as much information about a given vulnerability in the initial report as possible and must not attempt to stockpile bypasses. Programs should account for reports that contain additional bypass information and consider awarding a bonus when appropriate. | A hacker reports a path traversal vulnerability to a program, and the program fixes the vulnerability and “resolves” the report. A month later, the hacker finds a different payload that achieves the same impact as the original path traversal report. The program pays the report a new bounty. Or, a hacker reports an XSS vulnerability in a specific parameter, with a few example payloads. The program fixes the issue quickly and marks the report as Resolved. Behind the scenes, the program has used a WAF rule to block the XSS rather than fixing the underlying vulnerability. The hacker investigates again and finds that a different payload will trigger the same or a similar XSS. The program pays the report a new identical bounty and should invest in fixing the underlying vulnerability. |