Vulnerability Disclosure Guidelines

If there's a security vulnerability, we'd like to help out. By submitting a vulnerability to HackerOne, or signing up as a Response Team, you acknowledge that you have read and agreed to these guidelines. If you don't want to follow them, please don't sign up or submit anything to us.

Disclosure Philosophy

We believe effective disclosure requires mutual respect and transparency between researchers and response teams.

Researchers should...

  • Respect the rules. Operate within the rules set forth by the Response Team, or speak up if in strong disagreement with the rules.
  • Respect privacy. Make a good faith effort not to access or destroy another user's data.
  • Be patient. Make a good faith effort to clarify and support their research upon request.
  • Do no harm. Act for the common good through the prompt reporting of all discovered vulnerabilities. Never willfully exploit others without their permission.

Response Teams should...

  • Prioritize security. Make a good faith effort to resolve reported security issues in a prompt and transparent manner.
  • Respect research. Give researchers public recognition for their work.
  • Reward research. Financially incentivize security research when the team can afford to.
  • Do no harm. Not take unreasonable punitive actions against researchers, like making legal threats or referring matters to law enforcement.

Safe Harbor

We are committed to protecting the interests of Researchers. However, vulnerability disclosure is an inherently murky process. The more closely a Researcher's behavior matches these guidelines, the more we'll be able to protect you if a difficult disclosure situation escalates.

Submission Process

Response Teams will publish a set of rules designed to guide security research into a particular service or product. If you believe you have discovered a vulnerability, please submit a Bug Report through the HackerOne platform. The Bug Report should include a detailed description of your discovery with clear, concise reproducible steps or a working proof-of-concept. If you don't explain the vulnerability in detail, there may be significant delays in the disclosure process, which is undesirable for everyone.

The Bug Report will be updated with significant events, including when the vulnerability has been validated, when we need more information from you, or when you have qualified for a bounty.

Disclosure Process

The contents of the Bug Report will be made available to the Response Team.

  • This will occur immediately and automatically if the Response Team is registered on the HackerOne platform or we have previously identified an appropriate means of contact for the Response Team.
  • If there's no previously identified means of contact, we will make good faith effort to notify the Response Team through other reasonable means.
  • If we aren't able to contact the Response Team, the Bug Report will be made public 30 days after our initial contact attempt.

Disclosure Timelines

  • Default: The Bug Report will remain non-public to allow the Response Team sufficient time to publish a remediation. If either party requests public disclosure, the Bug Report will be made public within 30 days.
  • Mutual agreement: We encourage the Researcher and Response Team members to remain in open communication regarding disclosure timelines. If both parties are in agreement, the contents of the Bug Report can be made public on a mutually agreed timeline.
  • Protective disclosure: If the Response Team has evidence of active exploitation or imminent public harm, they may immediately provide remediation details to the public so that users can take protective action.
  • Extension: Due to complexity and other factors, we acknowledge the reality that some vulnerabilities may take longer than 30 days to remediate. In very unusual cases, the Bug Report may remain non-public to ensure the Response Team has an adequate amount of time to address a security issue. We encourage more capable Response Teams to hold themselves to stricter response times whenever possible.
  • Last resort: If a Response Team is unable or unwilling to issue a patch within 180 days, the contents of the Bug Report may be publicly disclosed. We believe transparency is in the public's best interest in these extreme cases.

Public Recognition

You'll receive public recognition for your find if 1) you are the first person to file a Bug Report for a particular vulnerability, 2) the vulnerability is confirmed to be a valid security issue, and 3) you have complied with these guidelines. If a Researcher prefers to remain anonymous, we encourage them to submit under a pseudonym.

Bounty Payments

Some Response Teams may offer monetary rewards for vulnerability disclosure. Not all Response Teams offer monetaty rewards, and the decision to grant a reward is entirely at their discretion. The amount of each bounty payment will be determined by the Response Team. Bounty payments are subject to the following eligibility requirements:

  • Because we're based in the United States, we aren't able to pay bounties to residents or those who report vulnerabilities from a country against which the United States has trade restrictions or export sanctions as determined by the U.S. Office of Foreign Assets Control (OFAC).
  • Minors are welcome to participate in the program. However, the Children's Online Privacy Protection Act restricts our ability to collect personal information from children under 13, so you will need to claim your bounties through your parent or legal guardian if you are 12 or younger.
  • All payments will be made in U.S. dollars (USD) and will comply with local laws, regulations and ethics rules. You are responsible for the tax consequences of any bounty you receive, as determined by the laws of your country.
  • It is your sole responsibility to comply with any policies your employer may have that would affect your eligibility to participate in this bounty program.


Response Team: A team of individuals who are responsible for addressing security issues discovered in a product or service. Depending on the circumstances, this might be a formal response team from an organization, a group of volunteers on an open source project, or an independent panel of volunteers.

Researchers: Also known as hackers. Anyone who has investigated a potential security issue in some form of technology, including academic security researchers, software engineers, system administrators, and even casual technologists.

Bug Report: A Researcher's description of a potential security vulnerability in a particular product or service. On HackerOne, Bug Reports always start out as non-public submissions to the appropriate Response Team.

Vulnerability: A software bug that would allow an attacker to perform an action in violation of an expressed security policy. A bug that enables escalated access or privilege is a vulnerability. Design flaws and failures to adhere to security best practices may qualify as vulnerabilities. Weaknesses exploited by viruses, malicious code, and social engineering are not considered vulnerabilities unless the Response Team says otherwise in the vulnerability scope.

Changes to These Guidelines

We may revise these guidelines from time to time. The most current version of the guidelines will always be at If we make changes that we believe will substantially alter your rights, we will email you and prominently display a notice on our site 7 days before we make those changes.


HackerOne is currently in beta and we are working to improve it. We welcome your questions, concerns, and feedback about these guidelines. If you have suggestions for us, please feel free to let us know at