[{"id":3772354,"new_policy":"# Table of Contents\n\n1. Program Scope\n2. Severity Definitions and Examples\n3. Test Plan\n4. Submission Guidelines\n5. Program Rules\n6. Appeal Process\n7. Response Targets\n8. Disclosure Policy\n9. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Severity Definitions and Examples\n\n## Critical\n\nCritical vulnerabilities are urgent security issues that present an ongoing or immediate danger to the users of our services and our infrastructure\n\n* Remote Code Execution\n* Authentication and Session Management Flaws (which lead to account compromise)\n* Disclosure of secrets in publicly accessible assets\n* Hardcoded credentials for a privileged user\n\n**Note that Critical vulnerabilities found in out of scope assets are awarded in the range of $500-$1000.**\n\n## High\n\n Typically, high severity issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.\n\n* Account takeover through Oauth misconfiguration\n* IDORs that bypass authentication or authorization for significant actions\n* CSRF on significant actions, such as changing email/passwords, deleting accounts, etc.\n* XSS resulting in conducting significant action (i.e., not defacement, phishing, cookie injection, etc.)\n* XML External Entity (XXE) attack\n* Hardcoded credentials for a non-privileged user\n\n## Medium\n\n Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. In addition to issues resulting from the lack of standard defense in depth techniques and security controls.\n\n* XSS (minor)\n* Domain takeovers supported by a proof of concept for `*.mozilla.org`, `*.mozilla.com`, `*.mozilla.net`, `*.firefox.com`, `*.mozgcp.net` and `*.mozaws.net` in addition to the list of sites in scope. If the domain is pointing to a claimed instance by another company, then the report will not be eligible for bounty.\n* SSRF which leads to reaching **internal** network hosts\n* Disclosure of sensitive information which does not expose the user or organization to immediate risk\n* CSRF for minor actions.\n\n## Low\n\n Minor security vulnerabilities which could lead to leaks or spoofs of non-sensitive information. Missing best practice security controls\n\n* XSS (blocked by CSP)\n* Clickjacking with demonstrated impact (Lack of clickjacking protection (XFO, CSP) is insufficient to claim a bounty)\n* External SSRF\n\n**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 their H1 page.**\n\n## Out of Scope\n\n* We follow HackerOne's standard for [Core Ineligible Findings](https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings).\n* In addition to the [custom scope exclusions](https://hackerone.com/mozilla?type=team#scope_exclusions) listed on our policy page\n\n## Misc Notes\n\nWe have a bug bounty panel whose members decide whether a report is eligible for bounty and the bounty amount for eligible reports. The panel meets on a weekly basis, except for holidays and vacations, to discuss bounty decisions.\n\nPlease note these are general guidelines, and reward decisions are up to the discretion of Mozilla.\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test only on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Make sure to use the provided submission template in the report.\n* We would like to have enough information to validate the report, but excessively verbose and long reports which don't include good information also create additional burden on the triage team.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported.\n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla_core_services/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}","{\"category\":\"Issues in Mozilla VPN Inspector\",\"details\":\"Issues discovered in Mozilla VPN in the web inspector while VPN is in development mode are out of scope, since the inspector exposes endpoints and methods to interact with the VPN for testing purposes.\"}"],"timestamp":"2026-04-08T17:20:07.270Z"},{"id":3772304,"new_policy":"# Table of Contents\n\n1. Program Scope\n2. Severity Definitions and Examples\n3. Test Plan\n4. Submission Guidelines\n5. Program Rules\n6. Appeal Process\n7. Response Targets\n8. Disclosure Policy\n9. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Severity Definitions and Examples\n\n## Critical\n\nCritical vulnerabilities are urgent security issues that present an ongoing or immediate danger to the users of our services and our infrastructure\n\n* Remote Code Execution\n* Authentication and Session Management Flaws (which lead to account compromise)\n* Disclosure of secrets in publicly accessible assets\n* Hardcoded credentials for a privileged user\n\n**Note that Critical vulnerabilities found in out of scope assets are awarded in the range of $500-$1000.**\n\n## High\n\n Typically, high severity issues are exploitable web vulnerabilities that can lead to the targeted compromise of a small number of users.\n\n* Account takeover through Oauth misconfiguration\n* IDORs that bypass authentication or authorization for significant actions\n* CSRF on significant actions, such as changing email/passwords, deleting accounts, etc.\n* XSS resulting in conducting significant action (i.e., not defacement, phishing, cookie injection, etc.)\n* XML External Entity (XXE) attack\n* Hardcoded credentials for a non-privileged user\n\n## Moderate\n\n Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. In addition to issues resulting from the lack of standard defense in depth techniques and security controls.\n\n* XSS (minor)\n* Domain takeovers supported by a proof of concept for `*.mozilla.org`, `*.mozilla.com`, `*.mozilla.net`, `*.firefox.com`, `*.mozgcp.net` and `*.mozaws.net` in addition to the list of sites in scope. If the domain is pointing to a claimed instance by another company, then the report will not be eligible for bounty.\n* SSRF which leads to reaching **internal** network hosts\n* Disclosure of sensitive information which does not expose the user or organization to immediate risk\n* CSRF for minor actions.\n\n## Low\n\n Minor security vulnerabilities which could lead to leaks or spoofs of non-sensitive information. Missing best practice security controls\n\n* XSS (blocked by CSP)\n* Clickjacking with demonstrated impact (Lack of clickjacking protection (XFO, CSP) is insufficient to claim a bounty)\n* External SSRF\n\n**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 their H1 page.**\n\n## Out of Scope\n\n* We follow HackerOne's standard for [Core Ineligible Findings](https://docs.hackerone.com/en/articles/8494488-core-ineligible-findings).\n* In addition to the [custom scope exclusions](https://hackerone.com/mozilla?type=team#scope_exclusions) listed on our policy page\n\n## Misc Notes\n\nWe have a bug bounty panel whose members decide whether a report is eligible for bounty and the bounty amount for eligible reports. The panel meets on a weekly basis, except for holidays and vacations, to discuss bounty decisions.\n\nPlease note these are general guidelines, and reward decisions are up to the discretion of Mozilla.\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test only on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Make sure to use the provided submission template in the report.\n* We would like to have enough information to validate the report, but excessively verbose and long reports which don't include good information also create additional burden on the triage team.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported.\n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla_core_services/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}","{\"category\":\"Issues in Mozilla VPN Inspector\",\"details\":\"Issues discovered in Mozilla VPN in the web inspector while VPN is in development mode are out of scope, since the inspector exposes endpoints and methods to interact with the VPN for testing purposes.\"}"],"timestamp":"2026-04-07T19:43:55.169Z"},{"id":3770820,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test only on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Make sure to use the provided submission template in the report.\n* Make sure to add supporting evidence for the bug by including screenshots and video PoC to clearly show the steps to reproduce\n* We would like to have enough information to validate the report, but excessively verbose and long reports which don't include good information also create additional burden on the triage team. This point also applies to follow up comments and answers to our questions.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}","{\"category\":\"Issues in Mozilla VPN Inspector\",\"details\":\"Issues discovered in Mozilla VPN in the web inspector while VPN is in development mode are out of scope, since the inspector exposes endpoints and methods to interact with the VPN for testing purposes.\"}"],"timestamp":"2026-03-10T16:04:05.935Z"},{"id":3768518,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test only on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Make sure to use the provided submission template in the report.\n* We would like to have enough information to validate the report, but excessively verbose and long reports which don't include good information also create additional burden on the triage team.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}","{\"category\":\"Issues in Mozilla VPN Inspector\",\"details\":\"Issues discovered in Mozilla VPN in the web inspector while VPN is in development mode are out of scope, since the inspector exposes endpoints and methods to interact with the VPN for testing purposes.\"}"],"timestamp":"2026-01-20T13:36:07.189Z"},{"id":3762817,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}","{\"category\":\"Issues in Mozilla VPN Inspector\",\"details\":\"Issues discovered in Mozilla VPN in the web inspector while VPN is in development mode are out of scope, since the inspector exposes endpoints and methods to interact with the VPN for testing purposes.\"}"],"timestamp":"2025-09-16T15:11:39.002Z"},{"id":3762607,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}","{\"category\":\"Cross Window Forgery\",\"details\":\"Reports of Cross Window Forgery are out of scope. CWF issues are known issues and we are working on a Mozilla wide solution for them.\"}"],"timestamp":"2025-09-10T16:54:07.412Z"},{"id":3756753,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Disclosure will be done every two weeks, on the first and third Tuesday of the month. This cadence is required to prepare our H1 triage pod for an increase in report volume after disclosing reports.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}"],"timestamp":"2025-06-03T08:20:49.618Z"},{"id":3738408,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}","{\"category\":\"Firefox Clients\",\"details\":\"Reports in Firefox clients are out of scope of our program and they should be submitted using the form: bugzilla.mozilla.org/form.client.bounty\"}"],"timestamp":"2024-09-11T11:15:19.149Z"},{"id":3738404,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Blind SSRF\",\"details\":\"Blind SSRF reports on services that are designed to load resources from the internet.\"}","{\"category\":\"Source Code Disclosure\",\"details\":\"Most of our code is open source and intentionally public\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}"],"timestamp":"2024-09-11T09:21:20.567Z"},{"id":3738403,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}","{\"category\":\"Executing scripts on sandboxed domains\",\"details\":\"Executing scripts on sandboxed domains (such as bmoattachments or mozillademos) are out of scope since we specifically created those domains to safely execute scripts.\"}","{\"category\":\"Denial-of-service attacks or issues related to rate limiting\",\"details\":\"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.\"}","{\"category\":\"Missing HTTP headers\",\"details\":\"Reports of missing HTTP headers are out of scope except as where their absence fails to mitigate an existing attack\"}"],"timestamp":"2024-09-11T09:12:32.867Z"},{"id":3738402,"new_policy":"# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}"],"timestamp":"2024-09-11T08:56:00.532Z"},{"id":3738401,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure. We appreciate your interest and effort in improving the security of our applications, and look forward to collaborating with you.","platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}"],"timestamp":"2024-09-11T08:53:01.091Z"},{"id":3737976,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}","{\"category\":\"Information Disclosure in open source projects\",\"details\":\"Information disclosure vulnerabilities are out of scope of our program. Most Mozilla projects and code are open source and content on most sites is intentionally public including employees and contributors names and email addresses which are used to attribute their contributions\"}"],"timestamp":"2024-09-05T10:31:55.991Z"},{"id":3733602,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently reported invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}","{\"category\":\"User credentials caches\",\"details\":\"Data dumps that include user email and password combinations could be obtained in many ways (indexing services, OSINT tools and web forums) and they do not help us identify any flaw in our software and are therefore out of scope for this bug bounty program.\"}"],"timestamp":"2024-07-24T10:56:14.320Z"},{"id":3733601,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":true,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":["{\"category\":\"List of frequently invalid reports\",\"details\":\"Frequently reported issues which do not pose a security risk to users and aren't eligible for a bounty such as the ones tracked in this tracker bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1830029\"}"],"timestamp":"2024-07-24T10:52:21.629Z"},{"id":3730694,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Submission Guidelines\n4. Program Rules\n5. Appeal Process\n6. Response Targets\n7. Disclosure Policy\n8. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Submission Guidelines\n\n* Make sure to review our program policy and scope before submitting to our program.\n* Our program policy lists an extensive list of out of scope vulnerabilities, including [invalid reports which are frequently reported](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029). Make sure the issue you are reporting is not one of them.\n* When reporting information disclosure vulnerabilities, note that most Mozilla projects and code are open source and content on most sites is intentionally public.\n\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-06-24T12:27:22.552Z"},{"id":3724699,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Program Rules\n4. Appeal Process\n5. Response Targets\n6. Disclosure Policy\n7. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-02T09:16:19.887Z"},{"id":3722176,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original security bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Program Rules\n4. Appeal Process\n5. Response Targets\n6. Disclosure Policy\n7. Safe Harbor\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see Severity Definitions and Examples above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla_core_services/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":true,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-04-01T08:48:16.969Z"},{"id":3713571,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original **security** bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Program Rules\n4. Appeal Process\n5. Response Targets\n6. Disclosure Policy\n7. Safe Harbor\n\n---\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research. Therefore, we have enabled the [Gold Standard Safe Harbor policy](https://hackerone.com/mozilla_core_services/safe_harbor) in our program.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-04T09:40:42.039Z"},{"id":3703731,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original **security** bugs in our web infrastructure.\n\n# Table of Contents\n1. Program Scope\n2. Test Plan\n3. Program Rules\n4. Appeal Process\n5. Response Targets\n6. Disclosure Policy\n7. Safe Harbor\n\n---\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Appeal Process\nHackers may appeal the decision made regarding the status of reports only once by commenting on the report and providing additional information to the report which demonstrates the impact of the reported issue on the asset. If no additional information is provided then the report status will be final.\n\nValid reasons for appeal:\n* The H1 triager closes the report as informative or duplicate and no longer responds to the hacker.\n* The report is closed as informative or duplicate and the hacker provides additional information which proves otherwise.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla's systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won't pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear to the Court, the public, or otherwise that we authorized your efforts to test and research the security of Mozilla's eligible systems and services.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-09-26T11:02:44.721Z"},{"id":3700004,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 5 days |\n| Time to Triage | 10 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla's systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won't pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear to the Court, the public, or otherwise that we authorized your efforts to test and research the security of Mozilla's eligible systems and services.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-17T08:58:43.210Z"},{"id":3699333,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless the bug is critical (see above for examples of critical issues)\n\n# Test Plan\n\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\n\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla's code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n* You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla's data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity. Please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Response Targets\n\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe'll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla's systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won't pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear to the Court, the public, or otherwise that we authorized your efforts to test and research the security of Mozilla's eligible systems and services.\n\nIf you're not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-02T15:07:47.618Z"},{"id":3690400,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* We ask that hackers test the application on the staging environment instead of the production environment. This will help ensure that any potential vulnerabilities are identified and addressed before they can be exploited in the production environment. Additionally, testing on the staging environment will help minimize any potential disruption to the production environment.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### Although we still appreciate being notified about them, the following issues fall outside the scope of our bug bounty program:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n* Information disclosure vulnerabilities. Most Mozilla projects and code are open source and content on most sites is intentionally public.\n* Check the list of bugs included in [this tracker bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029) for frequently reported issues which do not pose a security risk to users.\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-05T15:34:10.946Z"},{"id":3690081,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. \n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### Although we still appreciate being notified about them, the following issues fall outside the scope of our bug bounty program:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n* Information disclosure vulnerabilities. Most Mozilla projects and code are open source and content on most sites is intentionally public.\n* Check the list of bugs included in [this tracker bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029) for frequently reported issues which do not pose a security risk to users.\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-28T13:35:33.808Z"},{"id":3689930,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. Duplicate submissions within 72 hours will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a pro-rated additional bounty on top of the split.\n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### Although we still appreciate being notified about them, the following issues fall outside the scope of our bug bounty program:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n* Information disclosure vulnerabilities. Most Mozilla projects and code are open source and content on most sites is intentionally public.\n* Check the list of bugs included in [this tracker bug](https://bugzilla.mozilla.org/show_bug.cgi?id=1830029) for frequently reported issues which do not pose a security risk to users.\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-26T13:58:07.762Z"},{"id":3689376,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. Duplicate submissions within 72 hours will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a pro-rated additional bounty on top of the split.\n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### Although we still appreciate being notified about them, the following issues fall outside the scope of our bug bounty program:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-15T09:41:55.579Z"},{"id":3687699,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. Duplicate submissions within 72 hours will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a pro-rated additional bounty on top of the split.\n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### Although we still appreciate being notified about them, the following issues fall outside the scope of our bug bounty program:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n* Pocket iOS application until further notice\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-15T10:20:21.444Z"},{"id":3686950,"new_policy":"The Mozilla Bug Bounty Program is designed to encourage security research into Mozilla's websites and services and to reward those who find unique and original bugs in our web infrastructure.\n\n# Program Scope\n\nPlease check the list of sites under the Scope section, we would like testing to focus on those sites. Other sites and services are considered out of scope of the program unless you think the bug is critical. Please check our [website](https://www.mozilla.org/en-US/security/web-bug-bounty/) for examples of what we consider critical issues.\n\n# Program Rules\nPlease provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.\n\nTo be eligible for a reward under this program:\n\n* The security bug must be original and previously unreported. Duplicate submissions within 72 hours will split the bounty between reporters. If duplicate submissions are of unequal quality, the split will be at the level of the lesser report, and the greater report will receive a pro-rated additional bounty on top of the split.\n* The security bug must be a part of Mozilla’s code, not the code of a third party. We will pay bounties for vulnerabilities in third-party libraries incorporated into shipped client code or third-party websites utilized by Mozilla.\n* You must not have written the buggy code or otherwise been involved in contributing the buggy code to the Mozilla project.\n* You must be old enough to be eligible to participate in and receive payment from this program in your jurisdiction, or otherwise qualify to receive payment, whether through consent from your parent or guardian or some other way.\n * You must not be an employee, contractor, or otherwise have a business relationship with the Mozilla Foundation or any of its subsidiaries.\n* You should use your best effort not to access, modify, delete, or store user data or Mozilla’s data. Instead, use your own accounts or test accounts for security research purposes.\n* If you inadvertently access, modify, delete, or store user data, we ask that you notify Mozilla immediately at security@mozilla.org and delete any stored data after notifying us.\n* You should also use your best effort not to harm the availability or stability of our services, for example, by running aggressive scanning of those services. Instead, use a local development instance of the service that you want to test.\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n* You must not be on a US sanctions list or in a country (e.g. Cuba, Iran, North Korea, Crimea region of Ukraine, Sudan, and Syria) on the US sanctions list.\n* You must not exploit the security vulnerability for your own gain.\n* Before sharing any part of the security issue with a third party, you must give us a reasonable amount of time to address the security issue.\n* All submissions will be covered under [Mozilla's Website \u0026 Communications Terms of Use](https://www.mozilla.org/en-US/about/legal/terms/mozilla/), granting us permission to make use of all submissions.\n* All submissions must also abide by [HackerOne Code of Conduct](https://www.hackerone.com/policies/code-of-conduct) and [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).\n* Bounties can be donated to charity, please follow the [HackerOne process](https://docs.hackerone.com/hackers/payments.html#donating-bounties-to-charity) if you would like to donate your bounty money.\n* Do not threaten or attempt to extort Mozilla. We will not award a bounty if you threaten to withhold the security issue from us or if you threaten to release the vulnerability or any exposed data to the public.\n\n\n# Test Plan\n* Whenever it is explicitly stated in our program scope, you are expected to test on the provided instances (e.g. staging) instead of production.\n\n# Response Targets\nMozilla will make a best effort to meet the following SLAs for hackers participating in our program:\n\n| Type of Response | SLA in business days |\n| ------------- | ------------- |\n| First Response | 2 days |\n| Time to Triage | 2 days |\n| Time to Bounty | 30 days |\n| Time to Resolution | depends on severity and complexity |\n\nWe’ll try to keep you informed about our progress throughout the process.\n\n# Disclosure Policy\n* Our program discloses security reports when they are fixed and rewarded. We make exceptions in case reporters have a valid reason for not using full disclosure or when they need more time in the research before the report is disclosed. We can consider partial disclosure in those cases, we can discuss and agree on the type of disclosure.\n* Follow HackerOne's [disclosure guidelines](https://www.hackerone.com/disclosure-guidelines).\n\n# Out of scope vulnerabilities\n\n### The following issues are considered out of scope:\n\n* Self-XSS\n* Executing scripts on sandboxed domains (such as bmoattachments or mozillademos)\n* CSRF for non-significant actions (logout, forms with no sensitive actions, etc.)\n* Clickjacking attacks without a documented series of clicks that produce a vulnerability\n* Spam (including issues related to SPF/DKIM/DMARC)\n* Denial-of-service attacks or issues related to rate limiting\n* Attacks that require social engineering (phishing)\n* Content injection, such as reflected text or HTML tags\n* Missing HTTP headers, except as where their absence fails to mitigate an existing attack\n* Authentication bypasses that require access to software/hardware tokens\n* Vulnerabilities that only affect users with specific browsers (must work either in Firefox or Chrome)\n* Vulnerabilities that require access to passwords, tokens, or the local system (e.g. session fixation)\n* Assumed vulnerabilities based upon version numbers only\n* Source code disclosures, as most of our code is open source\n* Vulnerabilities discovered shortly after their public release\n* Outdated TLS configurations which remain to support downloads from Windows XP systems\n* Blind SSRF reports on services that are designed to load resources from the internet\n* Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors).\n* Pocket MacOS application\n* Pocket iOS application until further notice\n    \n# Safe Harbor\n\nMozilla strongly supports security research into our products and wants to encourage that research.\n\nAs a result, we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with this Bug Bounty Program, or for any accidental or good faith violation of this policy. This includes any claim under the DMCA for circumventing technological measures to protect the services and applications eligible under this policy.\n\nAs long as you comply with this policy:\n\n * We consider your security research to be \"authorized\" under the Computer Fraud and Abuse Act,\n * We waive any restrictions in our applicable Terms of Service and [Acceptable Use Policy]( https://www.mozilla.org/en-US/about/legal/acceptable-use/) that would prohibit your participation in this policy, for the limited purpose of your security research under this policy.\n\nWe understand that many Mozilla systems and services are interconnected with third-party systems and services. While we can authorize your research on Mozilla’s systems and services, and promise that Mozilla will not bring or threaten litigation against you for your efforts under this policy, we cannot authorize efforts on third-party products or guarantee they won’t pursue legal action against you. However, if a third party threatens or brings any legal action against you for your efforts under this policy, we are willing to make clear—to the Court, the public, or otherwise--that we authorized your efforts to test and research the security of Mozilla’s eligible systems and services.\n\nIf you’re not sure whether your conduct complies with this policy, please contact us first at security@mozilla.org and we will do our best to clarify.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-05-04T15:53:37.237Z"}]