Cloud Vulnerability Reward Program Rules
The Google Cloud Vulnerability Reward Program recognizes the contributions of security researchers who invest their time and effort in helping us secure our platform and our customers. Through this program, we provide monetary rewards and public recognition for novel vulnerabilities disclosed to us.
Services in scope
In principle, any Google Cloud product or web service that handles reasonably sensitive user data is intended to be in scope.
On the flip side, the program has several important exclusions to keep in mind:
- Google Workspace products – Products belonging to Google Workspace are out of scope for the Cloud VRP and should be reported to the Google VRP instead.
- 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 Cloud products and web services; 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
Important: The Cloud VRP does not authorize the testing of Google Cloud customer applications which are hosted on domains such as *.bc.googleusercontent.com or *.appspot.com. While Google Cloud customers can authorize penetration testing of their own applications (read more), testing of these domains is not within the scope of or authorized by the Cloud VRP.
The main reason why a reported issue may not qualify for a reward is because of low impact. Although we review each report on a case-by-case basis, we are sharing some of the common low-risk issues that typically do not earn a monetary reward:
- 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.
- 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 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 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.
- 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
The following table outlines typical rewards for the most common classes of bugs:
Severity Impact Category / Impact Tier | Examples | Google Cloud products on Tier 1 (IT1) | Google Cloud products on Tier 2 (IT2) | Default Google Cloud products (IT3) | Acquired Google Cloud products (IT3a) | Other acquisitions or lower priority Google Cloud products (IT3b, Generic) | |
---|---|---|---|---|---|---|---|
Vulnerabilities without any interaction or relationship between attacker and victim | |||||||
Breach of Google Cloud's production environment (S0) | (S0a)
|
$50,000 - $101,010 | $7,500 - $20,000 | ||||
|
(S0b)
|
$31,337 - $50,000 | $25,000 | $20,000 | $13,337 | $5,000-$7,500 | |
(S0c)
|
$25,000 | $20,000 | $13,337 | $10,000 | $3,133.7-$5,000 | ||
Vulnerabilities where the only pre-condition is the attacker having a role in, or belonging to, a Google Cloud organization, project, or resource, with no interaction between attacker and victim [1] | |||||||
Unauthorized read/modification of user data or workload configurations (S1) |
|
(S1a)
|
$20,000 | $13,337 | $10,000 | $7,500 | $3,133.7 |
(S1b)
|
$13,337 | $10,000 | $7,500 | $5,000 | $1,337 | ||
(S1c)
|
$5,000 - $10,000 | $3,133.7 - $7,500 | $1,337 - $5,000 | $500 - $3,133.7 | $500 | ||
Vulnerabilities due to the secure by design/default gaps | |||||||
Insecure by default (S2) |
|
$3,133.7 | $1,337 | $500 | $200 | Credit | |
Vulnerabilities requiring interaction between attacker and victim or with smaller security impact [2] | |||||||
Execute code on the client | Web: Cross-site scripting in cloud products, e.g. Google Cloud Console, SDK vulnerabilities | $20,000 | $15,000 | $10,000 | $500 | $200 | |
Other valid security vulnerabilities | Web: CSRF, Clickjacking | $5,000- $15,000 | $5,000- $15,000 | $1,337 - $10,000 | $500 | $200 |
[1] Downgrades would be applied if exploitation requires victim interaction or access to sensitive victim information that was not previously obtained through the vulnerability itself.
[2] For client-side vulnerabilities, the Google VRP rewards table is applicable, the amounts are repeated here for convenience only.
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.
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.
All bugs should be reported using the vulnerability form (in the Bug Location step, select Cloud VRP).
Note: If your report qualifies for a reward in a different/additional vulnerability reward program at Google, we will pass your report to the appropriate panel to ensure you receive the maximum possible payout.
We ask you to submit high-quality reports, with as many details as possible, including a proof of concept and instructions on reproducing the issue. Please also include a description of the issue’s impact and an attack scenario, as that helps us assess the vulnerability quickly and effectively. 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.
For tips on improving your reports, also refer to the Bug Hunter University.
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 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 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: If I report a valid vulnerability, will a CVE be issued?
A: We will issue CVEs for critical Google Cloud vulnerabilities.
Q: How will I know if the Google Cloud VRP will issue a CVE based upon one of my reports?
A: We will notify you through your Cloud VRP submission after assessing and working with the product team to understand the severity of the report.
Q: Can I choose not to have a CVE filed based upon one of my reports?
A: Unfortunately, no. We will be issuing CVEs for critical vulnerabilities in Google Cloud as part of our continued commitment to security and transparency.
Q: How will you credit researchers for CVEs issued based upon their VRP report?
A: We will be crediting the CVE to any researcher with a public profile. However, if you have a public profile but would prefer to be removed from the 'credits' field of the CVE, please let us know and we will ensure that you are not mentioned. Additionally, if you have a private profile and would like to be added to the 'credits' field, please let us know and we will happily do so, even after the CVE is published if necessary.
Q: Whom can I contact if I have questions about the CVE process?
A: Contact us via Google's VRP portal and either file a report for Google Cloud or ask in an existing report.
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.