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.
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:
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.
Please note that Google client applications (Android, Picasa, Google Desktop, etc) are currently not in scope. We may expand the program in the future.
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:
The following reports will be definitely excluded:
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.
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 | $5,000 |
| SQL injection or equivalent | $10,000 | $10,000 | $10,000 | $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.
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.
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. Feel free to 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. Oh: 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.
Q: Who determines whether my report is eligible for a reward?
A: The reward panel consists of members of the Google Security Team. The current permanent members are Adam Mein, Kevin Stadmeyer, Martin Straka, Eduardo Vela Nava, and Michal Zalewski with rotating membership from Matthew Dempsky, Thai Duong, Artur Janc, Mateusz Jurczyk, Billy Rios, 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 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, however.
Q: Are there any commonly reported vulnerabilities that are not clear-cut, and for which the panel 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. The ability to inject arbitrary JavaScript onto somebody else’s blog would likely qualify for a reward, however!
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 panel members:
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 Internet Explorer versions prior to 8.
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.
