Mozilla

Web and Services Bug Bounty Program

Introduction

The Mozilla Web Application Security Bug Bounty Program is designed to encourage security research in Mozilla websites and services and to reward those who help us protect Mozilla users data.

General Bounty Guidelines

Mozilla will pay a bounty for certain website and service security bugs, as detailed below. All security bugs must follow the following general criteria to be eligible:

  • Security bug must be original and previously unreported.
  • Security bug must be a remote exploit, compromise user data, allow access to Mozilla infrastructure or resources, or easily manipulate a user.
  • Submitter must not be the author of the buggy code nor otherwise involved in its contribution to the Mozilla project (such as by providing check-in reviews).
  • Employees of the Mozilla Foundation and its subsidiaries are ineligible.
  • Community volunteer members involved with bug handling/who have security bug access are not eligible during their period of involvement.

If two or more people report the bug together, or working independently at approximately the same time, the reward will be divided between them.

How To Submit Bugs

The sooner we can reproduce and fix the bug, the sooner we can validate it, fix it, and send your reward.

We prefer to receive bug reports in English. If English is not your native language and you are not fluent, Mozilla has employees and volunteers from all over the world who can help. If necessary, please write bug reports in your native language rather than using automated translation software. Automated translation software tends to mangle technical descriptions in indecipherable way.

There are three main things you can provide which will help us to evaluate your submission quickly and pay a bounty sooner:

  1. What is the attack scenario?
  2. What is the step-by-step exploit process?
  3. What is the security impact?

Please submit all bugs through the Bugzilla web bounty form. Do not submit bugs by email.

What is the attack scenario?

For the attack scenario, please describe how an attacker would use the bug you are submitting, any necessary conditions for it to work, and what the attacker would gain through successful attack. Please answer the following questions to the best of your ability:

  1. What is the necessary position of the attacker? (Example: Logged in to x website, unauthenticated, etc.)
  2. Are there any other assumptions that must be made about the victim? (Example: only affects specific web browser versions, requires that the user can be tricked into clicking on a link, etc.
  3. How might a malicious actor use this attack? (Example: Steal victim’s cookies, redirect to malicious website, read files on server outside web root, remote OS command injection, XSS users, etc.)

What is the step-by-step exploit process?

Please describe the multi-step process required, step by step, in the right order. If there are multiple parties involved, please describe them all clearly. For example:

  1. Visit the url https://xyz.firefox.com/somepage/form?name=value&name2=value2
  2. Log in
  3. Click the “Frobozz” button
  4. Place order for “Anti-Grue Cream” to shipping location “small mailbox,” continue navigation to the Shipping Address page.
  5. Add the following payload "><img src=x onerror=alert(document.domain);// > into the “City” field, then click Submit.
  6. The XSS payload ends up in the POST parameter name d oddly_angled_room
  7. Visitors to the page /puzzles are affected by stored XSS

Include the HTTP request(s) including any necessary header values and POST parameters with your bug submission.

Please avoid videos. They take time to create and much more time for us to interpret.

Repeat the attack using only your own description in order to prevent errors and omissions, update documentation.

XSS reporting tips

  • For a reflected XSS vulnerability, the affected URL with a working payload is usually sufficient. Please use alert(document.domain) and not alert(1) in your POC.
  • For any XSS vulnerability, please make sure to write down the attack scenario, which is different than the step-by-step exploit process. Where would the attacker have to be positioned in order to get the victim to trigger the exploit? What action would the victim need to follow? What would be the impact?
  • Self-XSS, where the attacker tricks users into copying and pasting malicious script content or other content into their browser, is not eligible for the Bug Bounty program.

Reward Guidelines

Mozilla will pay a bounty for website and service security bugs as detailed below. All security bugs must follow the following general criteria to be eligible:

  • Eligible security bugs may be present in any of eligible sites or services as outlined in the Web Application Security Bounty FAQ.
  • The security rating given by the Bounty Committee for a bug must be “sec-critical”, “sec-high” or “sec-moderate” in order for it to be eligible for a bounty. (See Web App Ratings for details of the rating qualifications.)
  • All bounties paid will be at the discretion of the Mozilla Bounty Committee, which will evaluate the severity of reported issues with the help of engineers who work on the affected code. Security researchers are invited to participate in the assignment of ratings, but final decisions on the rating are at the discretion of the Bounty Committee.

Rewards Amounts

Vulnerabilities found in Mozilla Web applications and services are eligible for bounties between $500 (USD) and $3000 (USD), for extraordinary or critical vulnerabilities in valid web applications or Mozilla services. Rewards for some critical sites can be even higher (e.g. FxAccounts, FindMyDevice, Update Services, Bugzilla)

Bounties will be awarded for sec-critical, sec-high, or sec-moderate rated security bugs that meet the following criteria:

  • Security bug is on the list of sites which part of the bounty. See the eligible bugs section of the Web Application Security Bounty FAQ for the list of sites which are included under the bounty.
  • More information about this program can be found in the Web Application Security Bounty FAQ.
  • The risk determination and bounty reward are based on the sole determination of the bounty committee after analysis of the bug, its impact, the difficulty of successful exploitation, and the resource impacted.