Introduction

This FAQ attempts to answer various questions about how the Mozilla security bounty program relates to Web Applications. This FAQ covers web applications and if you are reporting an issue unrelated to a web application security vulnerability, (e.g. a security issue in the Firefox browser), please see the original: Security Bug Bounty Program FAQ. For more about the background of the bug bounty program see the official guidelines governing the program.

General questions

Eligible bugs

Bug reporting

General questions

Why do we include web applications as part of our security Bug Bounty Program?

Many people are not aware that we have paid the bounty in the past on web application security vulnerabilities which impact client security. We are, however, expanding the bounty beyond web vulnerabilities which just affect the client. We also feel we should have a more formal structure around our web properties when it comes to paying a bounty because our goal is to make our products and services more secure.

How can I find potential vulnerabilities and are there things I shouldn't do in trying to find them?

We have received many questions around how to find web application security issues. The most common concern is the use of automatic tools. We ask that people don't use automatic tools against our web services as it is important to maintain our services and availability. We do encourage people to examine typical areas for vulnerabilities such as authentication and session management. Since our code is opensource, you are encourage to run on the software on your own server instance or just look at the source code for potential issues. (See the list below for the domains and applications which are in scope.)

Is the amount of the bounty different for web applications vulnerabilities?

In the past we have not formally paid the bug bounty on web vulnerabilities but we have paid the bounty for critical and extraordinary web application vulnerabilities. We are now going to include high severity web applications vulnerabilities. So we are giving a range starting at $500 (US) for high severity and, in some cases, may pay up to $3000 (US) for extraordinary or critical vulnerabilities.

Is there a list of severity ratings with examples?

Yes, here it is: Web Application Severity Ratings

Eligible bugs

Which domains and web applications will be considered to be part of the bug bounty?

Below is the list of domains under scope for Mozilla's web application security bug bounty. While this list doesn't include all the Mozilla web properties, we do plan on adding to this list as we introduce our web security process to other sites not included in this list.

  • bugzilla.mozilla.org
  • *.services.mozilla.com
  • aus*.mozilla.org
  • www.mozilla.com/org
  • www.firefox.com
  • www.getfirefox.com
  • addons.mozilla.org
  • services.addons.mozilla.org
  • versioncheck.addons.mozilla.org
  • pfs.mozilla.org
  • download.mozilla.org

The Mozilla Developer Network (developer.mozilla.org) has been removed from this list due to site vandalism by researchers looking for security issues. It will be added back at a later date when a test server is deployed to avoid negative impacts on our primary reference site.


What about sites which are not listed?

If you find an issue with a site which is not "officially" part under the web application bug bounty, we would still like to know. If the bug is extraordinary, we might still consider the bug to be nominated for a bounty. In the past we have paid for interesting bugs which are outside of normal policy.

What types of issues will be considered as part of the bounty program?

While there are many types of web vulnerabilities, the list below directly affects our users and our infrastructure. These are just a few examples.

  • Cross-Site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Injection / RFI/LFI

The Web Application Severity Ratings is consider to be the master list for what will be part of the bug bounty.

Why won't you provide a reward for denial of service bugs?

Because DoS bugs are generally less serious than other web application security bugs and in many cases a DoS doesn't need to involve a technical vulnerability within a web application. We have decided to concentrate our limited resources on rewarding people who find what we consider to be more serious security problems.

Bug reporting

Once I have found a vulnerability, what next?

Please file a bug describing the security bug. The security check-box should also be checked when filing the bug. Further details on the security check-box can be found here.

We also ask that you notify the Mozilla Security Group by email and include the bug number and a brief summary.

If I report the bug directly to you, do I have to keep the bug confidential and not publish information about it in order to receive a reward?

No. We're rewarding you for finding a bug, not trying to buy your silence. However if you report the bug through the standard Mozilla process and haven't already published information about it then we do ask that you follow the guidelines set forth in the official policy on handling Mozilla security bugs. Under this policy security-sensitive bug reports in our Bugzilla system may be kept private for a limited period of time to give us a chance to fix the bug before the bug is made public, with an option for the bug reporter (or others) to open the bug to public view earlier whenever circumstances warrant it (e.g., if you feel your bug report is being completely ignored).However, in the interest of protecting our users, we would appreciate a reasonable amount of time to address the issue before the information is publicly disclosed.

I don't have the time or desire to work with you further in investigating and fixing the bug; can I still get a bug bounty reward?

Yes. Again, we're rewarding you for finding a bug, not trying to buy your cooperation. However we do invite you to work together with us, and we hope that you'll accept that offer in the spirit in which it was intended. In return you'll get the opportunity to work as a full member of the team fixing your bug and see "from the inside" exactly how Mozilla security bugs get resolved.