Google and Alphabet Vulnerability Reward Program (VRP) Rules
We have long enjoyed a close relationship with the security research community. To honor all the cutting-edge external contributions that help us keep our users safe, we maintain a Vulnerability Reward Program for Google-owned and Alphabet (Bet) subsidiary web properties, running continuously since November 2010.
Services in scope
In principle, any Google-owned or Alphabet (Bet) subsidiary 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
- *.deepmind.com
- *.waymo.com
- *.wing.com
Bugs in Google- and Waymo-developed apps published in the Apple App Store will also qualify. For information on further services and devices that are in scope of different reward programs, see the rules for the following programs:
- Abuse Vulnerability Reward Program Rules
- Android and Google Devices Security Reward Program Rules
- Chrome Vulnerability Reward Program Rules
- ChromeOS Vulnerability Reward Program Rules
- Cloud Vulnerability Reward Program Rules
- Google Mobile Vulnerability Reward Program Rules
- Google Open Source Software Vulnerability Reward Program Rules
- Chrome Extensions Vulnerability Reward Program Rules
- Verily Bug Bounty Program Rules on HackerOne
On the flip side, the program has two important exclusions to keep in mind:
- Third-party websites – Some Google-branded services hosted in less common domains may be operated by our vendors or partners. We can't authorize you to test these systems on behalf of their owners and will not reward such reports. Please read the fine print on the page and examine domain and IP WHOIS records to confirm. If in doubt, talk to us first!
- Recent acquisitions – To allow time for internal review and remediation, newly acquired companies are subject to a six-month blackout period. Bugs reported sooner than that will typically not qualify for a reward.
Qualifying vulnerabilities
Any design or implementation issue 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,
- Mixed-content scripts,
- Authentication or authorization flaws,
- Server-side code execution bugs,
- XSLeak bugs.
Note that the scope of the program is limited to technical vulnerabilities in Google-owned browser extensions, mobile, and web applications; please do not try to sneak into Google offices, attempt phishing attacks against our employees, and so on.
Out of concern for the availability of our services to all users, please do not attempt to carry out DoS attacks, leverage black hat SEO techniques, spam people, or do other similarly questionable things. We also discourage the use of any vulnerability testing tools that automatically generate very significant volumes of traffic.
Non-qualifying vulnerabilities
Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the common low-risk issues that typically do not earn a monetary reward:
- Vulnerabilities in *.bc.googleusercontent.com or *.appspot.com. These domains are used to host applications that belong to Google Cloud customers. The Vulnerability Reward Program does not authorize the testing of Google Cloud customer applications. Google Cloud customers can authorize the penetration testing of their own applications (read more), but testing of these domains is not within the scope of or authorized by the Vulnerability Reward Program.
- Cross-site scripting vulnerabilities in “sandbox” domains (read more.) We maintain a number of domains that leverage the same-origin policy to safely isolate certain types of untrusted content; the most prominent example of this is *.googleusercontent.com. Unless an impact on sensitive user data can be demonstrated, we do not consider the ability to execute JavaScript in that domain to be a bug.
- Execution of owner-supplied JavaScript in Blogger. Blogs hosted in *.blogspot.com are no different from any third-party website on the Internet. For your safety, we employ spam and malware detection tools, but we do not consider the ability to embed JavaScript within your own blog to be a security bug.
- URL redirection (read more.) We recognize that the address bar is the only reliable security indicator in modern browsers; consequently, we hold that the usability and security benefits of a small number of well-designed and closely monitored redirectors outweigh their true risks.
- Legitimate content proxying and framing. We expect our services to unambiguously label third-party content and to perform a number of abuse-detection checks, but as with redirectors, we think that the value of products such as Google Translate outweighs the risk.
- Bugs requiring exceedingly unlikely user interaction. For example, a cross-site scripting flaw that requires the victim to manually type in an XSS payload into Google Maps and then double-click an error message may realistically not meet the bar.
- Logout cross-site request forgery (read more.) For better or worse, the design of HTTP cookies means that no single website can prevent its users from being logged out; consequently, application-specific ways of achieving this goal will likely not qualify. You may be interested in personal blog posts from Chris Evans and Michal Zalewski for more background.
- Flaws affecting the users of out-of-date browsers and plugins. The security model of the web is constantly being fine-tuned. The panel typically does not reward reports that describe issues that affect only the users of outdated or unpatched browsers.
- Presence of banner or version information. Version information does not, by itself, expose the service to attacks - so we do not consider this to be a bug. That said, if you find outdated software and have good reasons to suspect that it poses a well-defined security risk, please let us know.
- Email spoofing on Gmail and Google Groups. We are aware of the risk presented by spoofed messages and are taking steps to ensure that the Gmail filter can effectively deal with such attacks.
- User enumeration. Reports outlining user enumeration are not within scope unless you can demonstrate that we don't have any rate limits in place to protect our users.
- Bypassing the limit of accounts that can be verified with a given SMS number. We often receive reports about users being able to bypass our SMS limit for verifying accounts. There are actually two different quotas per number for account verification, one via 'SMS' and a different one via 'Call Me'.
Monetary rewards aside, vulnerability reporters who work with us to resolve security bugs in our products will be credited on the Leaderboard. If we file an internal security bug, we will acknowledge your contribution on that page.
Reward amounts for security vulnerabilities
The following table outlines the standard rewards for the most common classes of bugs, and the sections that follow it describe how these rewards can be adjusted to take into account characteristics such as report quality and other factors. To understand more about our general approach to vulnerability rewards, you can read our dedicated article.
Category | Examples | Google applications on Tier 0 domains [0], or global impact [1] (T0) | Google applications on Tier 1 domains [2] (T1) |
Normal Google Applications (T2) Examples include: *.google.com, *.youtube.com, *.blogger.com, *.admob.com |
Applications on acquisition Tier 0, Tier 1 domains [3][4] (T3a) |
Other acquisitions, other sandboxed or lower priority applications [4] (T3b) Examples include: *.withgoogle.com, *.withyoutube.com |
---|---|---|---|---|---|---|
Vulnerabilities giving direct access to Google servers | ||||||
Remote code execution (S0) | Command injection, deserialization bugs, sandbox escapes | $101,010 | $101,010 | $75,000 | $10,000 | $1,337 - $5,000 |
Unrestricted file system or database access (S1) | Unsandboxed XXE, SQL injection | $75,000 | $75,000 | $50,000 | $10,000 | $1,337 - $5,000 |
Logic flaw bugs leaking or bypassing significant security controls impacting SPII [5] (S2a) | SPII – Direct object reference, remote user impersonation | $50,000 | $50,000 | $31,337 | $5,000 | $500 |
Logic flaw bugs leaking or bypassing significant security controls impacting PII or other user confidential information (S2b) | PII or other user confidential information – Direct object reference, remote user impersonation | $31,337 | $20,000 | $13,337 | $2,500 | $500 |
Logic flaw bugs leaking or bypassing significant security controls impacting other data/systems (S2c) | Other – Direct object reference, remote user impersonation | $13,337 | $10,000 | $5,000 | $1,337 | $500 |
Vulnerabilities giving access to client or authenticated session of the logged-in victim | ||||||
Execute code on the client (C0) |
Web: Cross-site scripting Mobile / Hardware: Code execution |
$20,000 | $15,000 | $10,000 | $500 | $200 |
Other valid security vulnerabilities (C1) |
Web: CSRF, Clickjacking, XSLeaks Mobile / Hardware: Information leak, privilege escalation |
$5,000 - $15,000 | $5,000 - $15,000 | $1,337- $10,000 | $500 | $200 |
[0] Tier 0 domains are defined as domains where a critical vulnerability (e.g. XSS or authorization bypass) could lead to a compromise of a user's account or execution of code on their system.
[1] “Global impact” refers to any vulnerability that impacts a significant portion of the Internet, through integration with a product in Google VRP scope. For example, an XSS in Google Analytics embedded JavaScript.
[2] Tier 1 domains are defined as domains where a vulnerability could disclose particularly sensitive user data.
[3] Tier 0 and tier 1 acquisition domains are defined as domains where a compromise may lead to access of highly-sensitive information.
[4] Note that acquisitions qualify for a reward only after the initial six-month blackout period has elapsed.
[5] SPII is defined here.
The final amount is always chosen at the discretion of the reward panel. We understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you do so, we will double your donation – subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Report Quality
Rewards are adjusted based on the quality of the report. The main factors considered are:
- Demonstrated security impact of the reported vulnerability – Impact is judged based on the actual reported impact of the vulnerability, and not on a potential impact of the vulnerability. For example, reports related to API keys are often not accepted without a valid attack scenario (see Understanding API key leaks). Another example would be to make sure to fully demonstrate the impact of an XSS vulnerability (see When reporting XSS, don't use alert(1)).
- Overall report quality – See the following sections for details.
Exceptional Quality (1.5x reward amount)
An Exceptional Quality report has both of the following characteristics (in addition to the characteristics of a Good Quality report described below):
- Includes a proposed patch or effective mitigation to the vulnerability
- Includes a root cause analysis, which helps us find other similar variants of the issue
Good Quality (1x reward amount)
A Good Quality report has several of the following characteristics:
- An accurate and detailed description of the issue including any relevant version numbers for applications, OS, web browsers, hardware device models etc.
- A proof-of-concept that effectively, quickly, and easily demonstrates the vulnerability with any applicable reproduction output (e.g., video recording, APK file, etc.)
- A step-by-step explanation on how to reliably reproduce the vulnerability
- A succinct analysis and demonstration of the impact of the vulnerability
In addition to the characteristics listed above, we also expect the researcher to be responsive when asked questions and accurately answer any queries about the vulnerability
Low Quality (0.5x reward amount)
Reports which do not meet the criteria to qualify as Good Quality reports.
Common Precedents / Upgrades and Downgrades
While we try to account for everything, our table above is not perfect and cannot cover all possible situations. In complex situations, our rewards panel can still reward submissions, but will apply modifiers to the reward amount.
Precedents
Type | Amount | Reasoning |
---|---|---|
Incidents | $500 | Security issues that are not technical vulnerabilities. For example, a Googler accidentally sharing a confidential document publicly. |
3rd-party system | $100-$500 | Standard amount for an issue with a 3rd-party integration or configuration where Google controls the integration or configuration, but not the underlying application. |
Documentation update (security impacting) | $100-$500 | Standard amount for reports of incorrect documentation which is likely to lead to insecure states for users. |
Documentation update | HOF credit | Standard for reports of insufficient or incorrect documentation. |
Upgrades
Type | Amount | Reasoning |
---|---|---|
Panel discretion | +$1k | A standard bonus the panel can issue at their discretion. |
Time-limited bonus | +75% | Occasionally, we will publish time-limited bonuses for specific VRP targets. |
Swag | +??? | It’s a mystery how to receive this upgrade. |
Downgrades
The following table describes potential reasons for downgrades. A downgrade means your reward will be reduced by a predetermined step, for example $5000 will always step down to $3,133.7. Multiple downgrades can be applied.
Category | Reasoning |
---|---|
Impact | Downgrade applied for minor impact. |
Prior access | Downgrade applied because the attacker needs to have prior access to an impacted victim’s resource. |
Project access | Downgrade applied because the attacker needs to have access to an impacted victim’s project. |
User interaction | Downgrade applied because the attack requires significant user interaction by the victim. |
Exploitability | Downgrade applied because the attack is still possible, but we consider the vulnerability unexploitable in practice. Reports of this kind may also receive a reduced quality rating or not be accepted during triage depending on how likely an issue is to affect another user. |
Examples
Here are a few examples showing how the rules described above result in reward amounts:
Bug Description | Reward |
---|---|
An RCE in a server serving accounts.google.com, report is of exceptional quality (1.5x). | (T0, S0) $101,010 * 1.5 = $151,515 |
An IDOR on a *.google.com domain which can be used to exfil a user’s saved address (PII) to a third party, report is of normal quality (1x).
|
(T2, S2b) $13,337 * 1.0 = $13,337 |
An easy-to-exploit XSS which impacts all pages translated to English via Google Translate (“global impact” tier), report is of normal quality (1x). | (T0, C0) $20,000 * 1.0 = $20,000 |
A chat.google.com IDOR which can reveal the total number of messages a user has sent in the past 24 hours, report is of normal quality (1x). | (T1, S2c, with impact downgrade) $7,500 * 1.0 = $7,500 |
An XSS on a Tier 0 acquisition domain that is only exploitable after a million HTTP requests, report is of exceptional quality (1.5x). | (T3a, C1, with exploitability downgrade) $200 * 1.5 = $300 |
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 security vulnerability, please submit your report through the form available on our report page. Please be succinct: your report is triaged 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: What if I found a vulnerability, but I don't know how to exploit it?
A: We expect that vulnerability reports sent to us have a valid attack scenario to qualify for a reward, and we consider this to be a critical element of vulnerability research. Reward amounts are decided based on the maximum impact of the vulnerability, and the panel is willing to reconsider a reward amount, based on new information (such as a chain of bugs, or a revised attack scenario).
Q: How do I demonstrate the severity of the bug if I’m not supposed to snoop around?
A: Please submit your report as soon as you have discovered a potential security issue. The panel will consider the maximum impact and will choose the reward accordingly. We routinely pay higher rewards for otherwise well-written and useful submissions where the reporter didn't notice or couldn't fully analyze the impact of a particular flaw.
Q: I found an outdated software (e.g. Apache or Wordpress). Does this qualify for a reward?
A: Please perform due diligence: confirm that the discovered software had any noteworthy vulnerabilities, and explain why you suspect that these features may be exposed and may pose a risk in our specific use. Reports that do not include this information will typically not qualify.
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. But if the Make my profile public option in your profile is not selected, there won't be any public mention of you on our Leaderboard.
Q: What is the Leaderboard?
A: The dashboard for the participants in Google’s VRP program. It dynamically creates the 0x0A, Leaderboard, and Honorable Mentions lists.
Q: Is my profile data publicly available?
A: Only if you select the Make my profile public option in your profile. If you select this option, the data the profile holds is used on our Leaderboard, i.e. on the 0x0A, Leaderboard, and Honorable Mentions lists.
Q: How is the Honorable Mentions list sorted?
A: The list is sorted based on the volume of valid bug submissions, the ratio of valid vs. invalid submissions, and the severity of those submissions.
Q: My account was disabled after doing some tests. How can I get my account restored?
A: We recommend that you create an account dedicated only to testing before beginning any tests on our products, since we cannot guarantee that you will get access back to your account if it is disabled due to your testing activities. If you accidentally used a non-test account or you suspect your personal account was disabled due to your testing, you can request to have your account restored by Signing in to your Google Account and selecting Try to Restore.
Legal points
We are unable to receive reports and/or issue rewards to individuals or entities that are on sanctions lists, or who are in territories subject to sanctions (e.g., Cuba, Iran, North Korea, Syria, Crimea, and the so-called Donetsk People's Republic and Luhansk People's Republic). Additionally, due to administrative difficulties, we no longer issue rewards to individuals or entities located in Russia.
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.