Our Rewards Philosophy

Since the winter of 2010, a not-so-shadowy group of senior Googlers on our product security team meets every week to meticulously review and decide reward amounts for all bugs received through our Vulnerability Reward Program. The panel's task is to determine the impact of the security issues received in the preceding days, and to assign a consistent and fair reward amount to every notable find. This article is meant to shed light on how the panel decides rewards for the thousands of vulnerability reports it evaluates, and do not in any form alter the rules.

For every reported vulnerability, the security impact is evaluated by looking at the most dangerous attack scenario that the panel can come up with. We usually assign lower severity to problems that hinge on the existence of other, not-yet-discovered bugs to become exploitable; we do the same for findings that require extremely unlikely user interactions or other rarely-met prerequisites. On the flip side, when we can come up with higher-impact attack vectors that the original discoverer hasn’t considered in the submitted report, we bump up the score accordingly.

The impact is first measured by different tiers:

  1. The first, and highest tier (Remote Code Execution) is reserved for vulnerabilities that could give an attacker the unrestricted ability to execute arbitrary code.
  2. The second tier is reserved for vulnerabilities that could allow an attacker to potentially gain unrestricted access to service data such as SQL injection and file disclosure (e.g., via XML External Entities vulnerabilities).
  3. The third tier is reserved for server-side logic and authentication flaws that could allow an attacker to impersonate a user or an admin, and gain access to unauthorized data.
  4. The fourth tier is reserved for vulnerabilities that allow an attacker to obtain control of a user's session. This includes most types of XSS, as well as some of the more serious CSRF bugs (e.g., allowing you to change passwords or delegate access to accounts).
  5. The fifth and lowest tier is reserved for any other vulnerability that provides access only to a limited amount of information, allows for constrained, less serious user impersonation, or present any other type of real but less impactful risk to our users.

We also pay attention to the sensitivity of the affected services:

  1. The highest category of services is for serious vulnerabilities in services that provide near-complete control over user accounts. For Google web apps, this notably includes XSS flaws in the origin at https://accounts.google.com.
  2. The second category is used for services that could have been leveraged to attack multiple other users through a single compromised account (e.g., by tampering with a published extension in the Chrome Web Store), or to attack other, non-Google accounts belonging to the same user (e.g., Google Mail).
  3. The third category is reserved for those services that handle everyday, sensitive user data (YouTube, Google+, Hangouts, Drive, etc..). The bulk of subdomains within google.com fall into this category.
  4. The last category is for services that handle only fairly non-sensitive or constrained data, as well as for acquisitions acquired at least 6 months ago, and that run in their own independent infrastructure and haven't integrated to Google's engineering practices. This also includes non-sensitive applications running in App Engine and Google Compute Engine.

The usual reward amounts for these types of vulnerabilities are available in our rules page, which applies to most vulnerabilities. Over time, the amounts tend to change to provide balanced incentives for external researchers - especially as we find certain classes of targets more difficult to attack.

When receiving multiple reports, we typically only reward once per root cause and group similar vulnerabilities together. For example, if there's a service that accidentally disabled CSRF protection, we wouldn't issue a reward for every handler that had CSRF protection disabled, but would instead issue a reward for the most serious CSRF vulnerability in the code.

We might also give small bonus increases of around $1,000 USD for particularly clever or interesting vulnerabilities.