Program Rules

On November 2010, our security team launched a Vulnerability Reward Program for Google web properties. We have long enjoyed close cooperation with the security research community - and encouraged by the success of our Chrome Vulnerability Reward Program, we decided to take this step to invite cutting-edge external research that would help us keep our users safe.

Services in scope

Any Google-operated web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content in the following domains:

• *.google.com
• *.youtube.com
• *.blogger.com
• *.orkut.com

Please keep in mind that some Google-branded services hosted in less common domains may be operated by third parties. Because we can't authorize you to test these systems on behalf of their owners, please exercise due diligence. If in doubt, confirm with us first. The following checks are a good start:

• The site makes it clear that it is a Google product,
• The WHOIS records for the domain are in our name, and
• The IP address of the system is within an IP range registered to us.

In addition to Google-operated web properties, the following Google client applications are currently in scope:

• Google Wallet (Mobile application, API, Secure Element functionality)

Please note that all other Google client applications (Android, Picasa, Google Desktop, etc) are currently not in scope. We may expand the program in the future.

We make an important exception for acquired companies: for the first 6 months after the acquisition, the vulnerabilities in acquired platforms will usually not qualify for a reward. In addition to this, owing to the unusual nature and scale of this acquisition, vulnerabilities in Motorola products do not qualify for a reward and should be sent to security@motorola.com. We will revisit this exclusion if a decision is made to align our operations and security programs more closely.

Qualifying vulnerabilities

It is difficult to provide a definitive list of bugs that will qualify for a reward: any bug that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

• Cross-site scripting
• Cross-site request forgery
• Cross-site script inclusion
• Mixed scripting
• Flaws in authentication and authorization mechanisms
• Server-side code execution or command injection bugs.

The following reports are definitely excluded:

• Attacks against Google corporate infrastructure
• Social engineering and attacks on physical facilities
• Brute-force denial of service bugs
• SEO techniques
• Vulnerabilities in non-web applications
• Vulnerabilities in Google-branded services operated by third parties.

Out of concern for the availability of our services to all users, we ask you to refrain from using any tools that are likely to automatically generate significant volumes of traffic.

Reward amounts

Rewards for qualifying bugs range from $100 to $20,000. The following table outlines the usual rewards for the anticipated classes of bugs:

	accounts.google.com	Other highly sensitive services [1]	Normal Google applications	Non-integrated acquisitions and other lower priority sites [2]
Remote code execution	$20,000	$20,000	$20,000	$1,337 - $5,000
SQL injection or equivalent	$10,000	$10,000	$10,000	$1,337 - $5,000
Significant authentication bypass or information leak	$10,000	$5,000	$1,337	$500
Typical XSS	$3,133.7	$1,337	$500	$100
XSRF, XSSI and other common web flaws	$500 - $3,133.7 (depending on impact)	$500 - $1,337 (depending on impact)	$500	$100

[1] This category includes products such as Google Search (https://www.google.com), Google Wallet (https://wallet.google.com), Google Mail (https://mail.google.com), Google Code Hosting (code.google.com) and Google Play (https://play.google.com).

[2] Note that acquisitions qualify for a reward only after the initial 6 month blackout period has elapsed.

In each case, the ultimate decision is made by the reward panel and is at our discretion. In particular, we may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide that a single report actually constitutes multiple bugs; or that multiple reports are so closely related that they only warrant a single reward.

We understand that some of you are not interested in money. We also offer the option to donate your reward to charity. If you do, we will match it - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.

Regardless of whether you're rewarded monetarily or not, all vulnerability reporters who interact with us in a productive manner will be credited on the Hall of Fame. If we file a security bug internally, we will acknowledge your contribution on that page.

Investigating and reporting bugs

When investigating a vulnerability, please, only ever target your own accounts. Never attempt to access anyone else's data and do not engage in any activity that would be disruptive or damaging to your fellow users or to Google.

If you have found a vulnerability, please contact us at security@google.com. Please be succinct: the mailbox is attended by security engineers and a short proof-of-concept link is more valuable than a video explaining the consequences of an XSS bug. If necessary, you can use this PGP key.

Note that we are only able to answer to technical vulnerability reports. Non-security bugs and queries about problems with your account should be instead directed to Google Help Centers.

Frequently asked questions

Q: How do I prove that I could have obtained access to sensitive systems or data if I'm not supposed to copy or modify anything?

A: Please submit your report as soon as you have a suspicion that this is possible. Do not attempt to access sensitive files or user data. The panel will consider the maximum impact of the bug, and will choose the reward accordingly. We have routinely paid higher rewards even in cases where the reporter wasn't aware of the full consequences of the reported bug.

Q: Who determines whether my report is eligible for a reward?

A: The reward panel consists of the members of the Google Security Team. The current permanent members are Adam Mein, Artur Janc, Kevin Stadmeyer, Martin Straka, Eduardo Vela Nava, Tim Willis and Michal Zalewski with rotating membership from Alex Dobkin, Thai Duong, Ivan Fratrić, Mateusz Jurczyk, Fermin Serna and Michal Skladnikiewicz

Q: What happens if I disclose the bug publicly before you had a chance to fix it?

A: Please read our stance on coordinated disclosure. In essence, our pledge to you is to respond promptly and fix bugs in a sensible timeframe - and in exchange, we ask for a reasonable advance notice. Reports that go against this principle will usually not qualify, but we will evaluate them on a case-by-case basis.

Q: I found an outdated software (e.g. Apache or Wordpress). Does this qualify for a reward?

A: We ask you to perform due diligence: please confirm that the vulnerabilities fixed in the new version qualify for a reward, and try to determine if the site uses the vulnerable features. Reports that do not include this information will typically not qualify for a reward.

Q: I wish to report an issue through a vulnerability broker. Will my report still qualify for a reward?

A: We believe that it is against the spirit of the program to privately disclose the flaw to third parties for purposes other than actually fixing the bug. Consequently, such reports will typically not qualify.

Q: What if somebody else also found the same bug?

A: First in, best dressed. You will qualify for a reward only if you were the first person to alert us to a previously unknown flaw.

Q: My employer / boyfriend / dog frowns upon my security research. Can I report a problem privately?

A: Sure. If you are selected as a recipient of a reward, and if you accept, we will need your contact details to process the payment. You can still request not to be listed on our public credits page.

Q: Are there any commonly reported vulnerabilities that are not clear-cut that the panel has historically erred on the side of not issuing rewards?

A: Yes. In the spirit of transparency and to help focus external efforts, here is an overview of reports we most commonly reject:

• Vulnerabilities in Google-branded services maintained by third parties: There is a small number of (typically minor) Google-branded sites operated by external companies: for example, Google Store is operated by Merchandise Mania. For obvious reasons, we cannot authorize you to test such servers on behalf of these companies - and therefore, we regrettably can’t consider any eventual reports as in scope for our reward program.

  Before getting started with any security testing, we ask you to confirm that the service is actually operated by Google: examining WHOIS and DNS records, and reading the fine print on the target page itself, should offer sufficient insight.

• Cross-site scripting vulnerabilities in “sandbox” domains: Google maintains a number of “sandbox” domains designed specifically to take benefit of the same-origin policy to securely isolate certain classes of untrusted content and keep it completely separate from sensitive google.com interfaces. The two most prominent examples of this are googleusercontent.com and gmodules.com.

  The panel will usually deem reports of script execution vectors in these domains to be non-qualifying, unless it can be demonstrated that the design directly jeopardizes the security of any sensitive user data.

• URL redirection: Some members of the security community argue that open redirectors are a security issue. The common argument in favor of this view is that some users, when presented with a carefully crafted link, may be duped into thinking that they will be taken to a trusted page - but will be not be attentive enough to examine the contents of the address bar after the redirection takes place.

  On the other hand, we recognize that the address bar is the only reliable security indicator in modern browsers; and consequently, we think that any user who could be misled by a URL redirector can also be tricked in other ways, without relying on any particular trusted website to act as a relying party.

  The reward panel will likely deem URL redirection reports as non-qualifying: while we prefer to keep their numbers in check, we hold that the usability and security benefits of a small number of well-implemented and carefully monitored URL redirectors tend to outweigh the true risks.

• Legitimate content proxying and framing: The panel applies similar reasoning to most cases of content proxying and framing - for example, to page previews in Google Image Search and Google Translate, cached page views in Web Search and user-created gadgets on iGoogle.

  In general, we expect our services to label third-party content unambiguously and to perform a number of malware and abuse detection checks. However, we recognize that well-implemented content proxying brings innovative and unique functionality to many of our user-oriented services, and similarly to URL redirection, we believe that usability benefits substantially outweigh the risks.

  When it comes to framed third-party content, we recognize that framebusting is an interesting – and still unsolved – vector for petty mischief. To that effect, Google actively participates in efforts to rework the browser frame model – e.g., through the proposed HTML5 sandbox attribute. That said, as with many other architectural improvements attempted today, it will be a while before this problem is fully eradicated.

• Execution of owner-supplied JavaScript on Blogger: Blogger users are permitted to place custom JavaScript in their own blog templates and blog posts; our take on this is that blogs are user-generated content, not different from any third-party website on the Internet. Naturally, for your safety, we do employ spam and malware detection technologies - but we believe that the flexibility in managing your own content is essential to the success of our blogging platform.

  Therefore, the ability to execute owner-supplied scripts on your own blog is not considered to be a vulnerability. That being said, the ability to inject arbitrary JavaScript onto somebody else’s blog would likely qualify for a reward!

• Logout cross-site request forgery: At this time, the ability of malicious web sites to log users out of unrelated web applications is essentially unavoidable; it is a consequence of how the web is designed and cannot be reliably prevented by any single website. You might be interested in the following personal blog posts published a while ago on this topic by two Google employees:
  • “Logout XSRF – significant web app bug?” (Chris Evans)
  • “HTTP cookies, or how not to design protocols” (Michal Zalewski)

  Consequently, in most cases, the panel will not consider reports of the ability to log out users from Google as qualifying for the reward. Difficult, long-term browser-level improvements are required to truly eliminate this possibility.

• Flaws present only when using out-of-date browsers and plugins: The security model of the web is being constantly fine-tuned and improved by the vendors and by the security community. The panel will typically not reward reports of vulnerabilities that affect only the users of outdated or unpatched browsers. In particular, as of April 2012, we have decided to exclude all Internet Explorer versions prior to version 8.

Legal points

We are unable to issue rewards to individuals who are on sanctions lists, or who are in countries (e.g. Cuba, Iran, North Korea, Sudan and Syria) on sanctions lists. You are responsible for any tax implications depending on your country of residency and citizenship. There may be additional restrictions on your ability to enter depending upon your local law.

This is not a competition, but rather an experimental and discretionary rewards program. You should understand that we can cancel the program at any time and the decision as to whether or not to pay a reward has to be entirely at our discretion.

Of course, your testing must not violate any law, or disrupt or compromise any data that is not your own.