google.cat
External Program
Submit bugs directly to this organization
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 [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#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 [https://apps.apple.com/developer/google-inc/id281956209](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:
[/about/rules/5238081279623168/abuse-vulnerability-reward-program-rules](Abuse Vulnerability Reward Program Rules)
[/about/rules/5222232590712832/ai-vulnerability-reward-program-rules](AI Vulnerability Reward Program Rules)
[/about/rules/6171833274204160/android-and-google-devices-security-reward-program-rules](Android and Google Devices Security Reward Program Rules)
[/about/rules/5745167867576320/chrome-vulnerability-reward-program-rules](Chrome Vulnerability Reward Program Rules)
[/about/rules/4919474699501568/chromeos-vulnerability-reward-program-rules](ChromeOS Vulnerability Reward Program Rules)
[/about/rules/4849867320328192/cloud-vulnerability-reward-program-rules](Cloud Vulnerability Reward Program Rules)
[/about/rules/6618732618186752/google-mobile-vulnerability-reward-program-rules](Google Mobile Vulnerability Reward Program Rules)
[/about/rules/6521337925468160/google-open-source-software-vulnerability-reward-program-rules](Google Open Source Software Vulnerability Reward Program Rules)
[/about/rules/5668215344988160/chrome-extensions-vulnerability-reward-program-rules](Chrome Extensions Vulnerability Reward Program Rules)
[https://hackerone.com/verily_life_sciences](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 [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#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,
[/learn/invalid-reports/web-platform/xsleaks/5022006283862016/xsleaks-and-xs-search](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 [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#non-qualifying-vulnerabilities](
)
Note: Visit our [/learn](Bug Hunter University) page dedicated to common non-qualifying findings and 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 ([https://cloud.google.com/security/](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 ([/learn/invalid-reports/web-platform/xss/6619189462433792](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 ([/learn/invalid-reports/navigation/6680364896223232](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 ([/learn/invalid-reports/web-platform/csrf-clickjacking/5072689380982784](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 [http://scarybeastsecurity.blogspot.com/2010/01/logout-xsrf-significant-web-app-bug.html](Chris Evans) and [http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html](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 [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#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 [/about/rules/4737983938560000](dedicated article).
Category |
Examples |
Google applications on [https://github.com/google/bughunters/blob/main/domain-tiers/external_domains_google.asciipb](Tier 0) domains [0], or global impact [1] (T0) |
Google applications on [https://github.com/google/bughunters/blob/main/domain-tiers/external_domains_google.asciipb](Tier 1) domains [2] (T1) |
Normal Google Applications (T2)
Examples include: *.google.com, *.youtube.com, *.blogger.com, *.admob.com |
Applications on acquisition [https://github.com/google/bughunters/blob/main/domain-tiers/external_domains_acquisitions.asciipb](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, /learn/invalid-reports/web-platform/xsleaks/5022006283862016/xsleaks-and-xs-search
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 https://developers.google.com/standard-payments/reference/glossary#spii.
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. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Report Quality [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#report-quality](
)
We reward for quality because it facilitates the triage, analysis, and remediation process. Thus, we adjust the final rewards by a factor, based on the quality of the report [0.8x, 1x, or 1.2x]. The quality determination is made at the sole discretion of the panel.
We expect that all conditions below should be met to reach the good/exceptional reward tier:
Report quality dimensions
|
Dimension
| Low (0.8x reward amount)
| Good (1x reward amount)
| Exceptional (1.2x reward amount)
|
Content of your report
|
Vulnerability description
Explanation of issue
| Not present, incomplete or incorrect
| Incomplete, but still correct
| Effectively described
|
Attack preconditions
| Not present, incomplete or incorrect
| Incomplete, but still correct
| Effectively described
|
Impact analysis
Description of the security impact after successful exploitation (unless impossible to analyze without attacking non-test users or otherwise breaking the VRP rules)
| Not present, incomplete or incorrect. Theoretical or speculative impact
| Incomplete, but still correct
| Effectively and succinctly described (including relevant product-specific analysis), or impossible to analyze without attacking non-test users or otherwise breaking the VRP rules
|
Reproduction steps / PoC
Instructions on how to reproduce the issue
| Not present, incomplete or incorrect
| Present, only minor inaccuracies
| Present and complete, easy to understand and reproduce. An automated PoC is provided when possible *
|
Reproduction steps / POC properties
|
> Target/product information
Device, version, URLs. etc.
| Not present, incomplete or incorrect
| Full target information such as product name, version, hostnames, etc. provided when appropriate
| Full target information such as product name, version, hostnames, etc. provided when appropriate
|
> Reproduction output
Fuzzer, video, debugger, HTTP responses, etc.
| Not present, incomplete or incorrect
| Present, but missing information
| Effectively and succinctly shows the issue
|
Communication regarding your report
|
Researcher responsiveness
| Significant communication delays, incomplete or factually incorrect responses, non-technical discussions, AI slop
| Best effort responses (<2 week) and/or lacking notable information
| Fast (<3 workdays), concise, technically precise and clear responses with necessary information
|
Once a report is triaged (usually when a bug is filed with the product team), our security team begins the process of remediating the vulnerability. To maintain consistency and efficiency, we can only consider the information available prior to triage when determining the reward. Subsequent additions to the report will usually not affect the reward rating. Note that certain quality dimensions can be disregarded by the panel if they are not applicable or impossible for a researcher to determine.
Common Precedents / Upgrades and Downgrades [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#common-precedents-upgrades-and-downgrades](
)
While we try to account for everything, our rewards table 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.
)
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. |
)
Type | Amount | Reasoning |
Novelty | +$1k - +$5k | A bonus for truly unique reports that caused our security teams to think differently about a problem. [1] |
Time-limited bonus | +75% | Occasionally, we will publish https://bughunters.google.com/about/rules/other/5429687846305792/bonus-awards-rules bonuses for specific VRP targets. |
Swag | +??? | It’s a mystery how to receive this upgrade. |
[1] Discretionary bonuses are reserved for exceptional contributions that exceed standard reward criteria and demonstrate unique value. This award is based on subjective factors and is not tied to any specific metric or attribute of the report or researcher. The goal is to acknowledge novel contributions beyond standard reward criteria, while ensuring fairness and impartiality.
)
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. |
Drive ID knowledge | Downgrade applied because the attacker needs to know the value of a Drive ID to exploit the issue, and the way to retrieve it has not been demonstrated. |
OAuth consent (standard) | Downgrade applied because the attacker needs to obtain OAuth consent from the victim for scopes beyond 'userinfo.email' and 'userinfo.profile'. |
OAuth consent (sensitive) | Additional downgrade applied for requiring a sensitive scope as the malicious application needs to be verified first and the way to verify it has not been demonstrated. |
OAuth consent (restricted) | Additional two downgrades applied for requiring a restricted scope as the malicious application needs to be verified first and the way to verify it has not been demonstrated. |
)
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.2x).
| (T0, S0)
$101,010 * 1.2 = $121,212
|
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 http://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 [https://github.com/google/bughunters/blob/main/domain-tiers/external_domains_acquisitions.asciipb](Tier 0) acquisition domain that is only exploitable after a million HTTP requests, report is of exceptional quality (1.2x).
| (T3a, C1, with exploitability downgrade)
$200 * 1.2 = $240
|
Investigating and reporting bugs [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#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.
Note: Visit our [/learn](Bug Hunter University) articles to learn more about sending good vulnerability reports.
If you have found a security vulnerability, please submit your report through the form available on [/report](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 [https://services.google.com/corporate/publickey.txt](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 [https://support.google.com/user-security](Google Help Centers).
Code of conduct [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#code-of-conduct](
)
To ensure a healthy and productive relationship between bug hunters and the Google teams interacting with them, we have defined a [/about/rules/other/6009584292331520/code-of-conduct-for-our-vulnerability-reward-programs](Code of Conduct) laying out the expected behaviors from both sides.
Thank you in advance for familiarizing yourself with this code and adhering to its provisions!
Frequently asked questions [https://bughunters.google.com/about/rules/google-friends/google-and-alphabet-vulnerability-reward-program-vrp-rules#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 [/learn/improve-your-reports/how-to-report/6379261818306560](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 [http://googleonlinesecurity.blogspot.com/2010/07/rebooting-responsible-disclosure-focus.html](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 [https://accounts.google.com/Login](Signing in to your Google Account) and selecting Try to Restore.
)
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 or Belarus.
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.