Mozilla's add-on policies say an add-on may transmit only the data needed for its function, and only use it for its stated purpose. Personal data needs explicit opt-in, technical and interaction data must be opt-out, and private browsing data must not be stored. Remote code execution and unencrypted transmission are not allowed.
The core rules
From the policy page:
- Limit data transmission to what is necessary for functionality, used only for its stated purpose.
- Do not send search terms to third party search providers, ancillary data the add-on does not need, or browsing activity except as part of the primary function.
- Give users a clear way to control data transmission, using the add-on's own consent experience or Firefox's built-in consent system.
- Personal data requires explicit opt-in. Technical and user interaction data must be opt-out, and declining must not restrict functionality.
- Data from private browsing sessions must not be stored, and cross-session identifiers must not be exposed to web content.
- Do not load remote code for execution, relax page security headers such as Content Security Policy, or transmit data without encryption.
- Request only the permissions needed.
How the consent mechanics differ by version
| Add-on compatibility | Consent approach |
|---|---|
| Firefox 140 or later using the built-in system | State data practices accurately in the manifest, including when no data is collected |
| Firefox 139 or earlier, or not using the built-in system | Offer consent immediately after installation, on an unmissable single page without deceptive design |
Check the current policy before building, since these rules change by browser version.
What a reviewer or buyer should look for
- Declared data practices. Does the manifest or listing say what is collected, or does it say nothing?
- Match to behaviour. Compare the declaration with network requests seen in a test profile.
- Opt-in versus opt-out. Personal data should not be on by default.
- Functionality when declined. Features must still work if the user says no to technical data.
- Encryption. Traffic should not use plain HTTP.
- Permissions. Compare to what the feature needs.
A short test method: install in a clean profile with a proxy, use the main feature, and log every domain contacted. Any domain not explained by the listing is a question for the publisher.
Where this meets your policies
If your company has a data protection process, treat an extension as a processor of whatever the browser hands it. The add-on policy gives you a baseline to refer to in your approval record, but it does not replace your own assessment of purpose, retention and transfers.
Keep the approved version and the declared data practices in the same record. When the add-on updates, compare declarations. Changes to what is collected are the moment consent rules matter most.
Enforcement
The policies say Mozilla may reject or block affected versions or entire add-ons that do not comply. It may contact developers and allow reasonable time to fix problems before a block. Blocking may be immediate if an add-on appears to intentionally or repeatedly violate policies, or if developers are unreachable or uncooperative. Accounts on addons.mozilla.org may be blocked or deleted for certain violations.
Safeguard's compliance and evidence automation can hold the approval record, and dependency scanning covers what the add-on bundles.
Quick check
Is opt-in required for all data?
No. Personal data needs explicit opt-in. Technical and user interaction data must be opt-out.
Can an add-on store private browsing data?
No. The policy says data from private browsing sessions must not be stored.
Can a Firefox add-on load code from a server?
The policy says add-ons must not load remote code for execution.
Sources
Last reviewed: 19 October 2026.
