Web Bug Bounty FAQ

General questions

Eligible bugs

Bug reporting

General questions

Why do we include web applications as part of our bug bounty program?

Mozilla client software relies heavily on web services, and Mozilla’s community uses our websites and services to communicate and coordinate activity. Our goal is to make these products and services as safe and secure as possible.

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

We have received many questions around how to discover web application security issues, largely revolving around use of automated attack tools such as ZAP and Burp.

We request that people refrain from using automated tools against our production web services, as it is important to maintain our services' availability and minimize unintentional vandalism. Since our code is open source, you are encouraged to run it on your own server instance or examine the it directly for potential issues.

Eligible bugs

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

Only a limited subset of our websites are eligible for monetary payouts. Please see our HackerOne Mozilla policy page for additional information. Note that some low severity issues are not eligible for monetary awards based on their impact. We will recognize the reporter by thanking them on the Thanks page.

Why don’t you provide a reward for denial-of-service bugs?

Denial-of-services bugs are generally less serious than other web application security bugs and in many cases don't require a technical vulnerability within the web application.

Bug reporting

Once I have found a vulnerability, what next?

The sooner we can reproduce the bug, the sooner we can fix it and send you your bounty. Please submit all bugs to our HackerOne program Mozilla. Do not send vulnerabilities via email and please avoid using video.

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?

Once you have written your step-by-step instructions, repeat the attack by following them exactly. This helps prevent errors and omissions in your submission.

We prefer to receive bug reports in English. If English is not your native language and you are not fluent, please submit bugs in your native language. Please note that this may delay our response time.

If I report the bug directly to you, do I have to keep the bug confidential to receive a bounty?

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 keep the bug private for a limited period of time to give us a chance to fix the bug before the bug is made public.

Bug reporters may 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 interests of protecting our users, we would appreciate a reasonable amount of time to address the issue before the information is publicly disclosed.

If I don’t have the time to assist you further, can I still receive a bug bounty?

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 and see exactly how Mozilla security bugs are resolved.

What does a valid attack scenario look like?

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 a successful attack.

Please answer the following questions to the best of your ability:

  1. What is the necessary position of the attacker?
    • Do you need to be logged in or unauthenticated?
    • Do certain cookies need to be set?
    • Do you need to connect from a specific system?
  2. Are there any other assumptions that must be made about the victim?
    • Do they need to be running a specific web browser?
    • Does the victim need to be tricked into clicking on a specific link?
    • Does the user need to be a member of a specific group?
  3. How might a malicious actor use this attack?
    • Stealing a victim's session information
    • Redirect users to malicious websites
    • Read files on server outside the web root
    • Executing remote OS commands
    • XSSing users
What does a valid step-by-step exploit process look like?

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

  1. Visit https://shop.firefox.com/order?name=value&name2=value2
  2. Click the "Log in" link and login
  3. Click the "Order" button
  4. Place order for "Firefox Plush"
  5. Continue navigation to the Shipping Address page
  6. Add the following payload "><img src=x onerror=alert(document.domain);// > into the "City" field, then click Submit
  7. The XSS payload ends up in the POST parameter named city_order
  8. Visitors to the page /past_orders_by_city are affected by stored XSS

Include the HTTP request(s), any necessary header values and/or POST parameters along with your bug submission.

Once you have written your step-by-step instructions, repeat the attack by following them exactly. This helps prevent errors and omissions in your submission.

How should I report an XSS vulnerability?

For a reflected XSS vulnerabilities, the affected URL along with a working payload is usually sufficient. For stored XSS attacks, please describe the step-by-step exploit process, as above.

Please use alert(document.domain) and not alert(1) in your proof-of-concept.

Self-XSSes — where the attacker tricks users into copying and pasting malicious script content — are not eligible for bounties.