Google 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 web properties, running continuously since
November 2010.

Services in scope

In principle, any Google-owned web service that handles reasonably sensitive user data is
intended to be in scope. This includes virtually all the content in the following domains:

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 (this notably includes zagat.com). 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.

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:

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 being constantly fine-tuned. The panel will typically not
reward any problems that affect only the users of outdated or unpatched browsers. In
particular, we exclude Internet Explorer prior to version 9.

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.

Monetary rewards aside, vulnerability reporters who work with us to resolve security bugs
in our products will be credited on the Hall of Fame. If we file an
internal security bug, we will acknowledge your contribution on that page.

Reward amounts

New! To read more about our approach to vulnerability rewards you can read
our Bug Hunter University article here.

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

Category

Examples

Applications that permit taking over a Google account [1]

Other highly sensitive applications [2]

Normal Google applications

Non-integrated acquisitions and other sandboxed or lower priority applications [3]

Vulnerabilities giving direct access to Google servers

Remote code execution

Command injection, deserialization bugs, sandbox escapes

$20,000

$20,000

$20,000

$1,337 - $5,000

Unrestricted file system or database access

Unsandboxed XXE, SQL injection

$10,000

$10,000

$10,000

$1,337 - $5,000

Logic flaw bugs leaking or bypassing significant security controls

Direct object reference, remote user impersonation

$10,000

$7,500

$5,000

$500

Vulnerabilities giving access to client or authenticated session of the logged-in
victim

Execute code on the client

Web: Cross-site scriptingMobile: Code execution

$7,500

$5,000

$3,133.7

$100

Other valid security vulnerabilities

Web: CSRF, ClickjackingMobile: Information leak, privilege escalation

$500 - $7,500

$500 - $5,000

$500 - $3,133.7

$100

[1] For example, for web properties this includes some vulnerabilities in Google
Accounts (https://accounts.google.com).

[3] Note that acquisitions qualify for a reward only after the initial six-month
blackout period has elapsed.

The final amount is always chosen at the discretion of the reward panel. In particular, we
may decide to pay higher rewards for unusually clever or severe vulnerabilities; decide to
pay lower rewards for vulnerabilities that require unusual user interaction; 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 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.

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 goo.gl/vulnz. Please be succinct: the contact form 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: 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 it as a
critical step when doing 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 chose 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: 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 Artur Janc, Eduardo Vela Nava, Jeremy Zimmer, Martin Straka, and
Michal Zalewski. In addition there is a rotating member from the rest of
our team.

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.

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: What is bughunter.withgoogle.com?

A: The dashboard for the participants in Google’s VRP program. It dynamically creates the
hall of fame, i.e., the 0x0A and honorable mentions lists.

Q: Do I need a profile on bughunter.withgoogle.com to participate in the VRP?

A: No. You can participate in the VRP under the same rules without the need of a profile.
However, if you want your name to be listed in the 0x0A or the honorable mentions lists,
you need to create a profile.

Q: Is the profile data publicly available?

A: Yes. The profile holds the data that is currently already available now on our hall of
fame, i.e., on the 0x0A and honorable mentions lists. You can always leave these fields
blank.

Q: How is the honorable mentions list sorted?

A: The hall of fame is sorted based on the volume of valid bug submissions, the ratio of
valid vs. invalid submissions, and the severity of those submissions.

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.