Safeguard
Supply Chain•

Firefox add-on review: source code, minification and obfuscation

Mozilla requires readable source and a build recipe for add-ons and bans obfuscation. What the rules say and what they mean for the add-ons you install.

Safeguard Security Team
3 min read

Mozilla's add-on policies say code must be reviewable. If an add-on is minified or machine generated, the developer must hand over the original source and instructions to reproduce the build. Obfuscated code is prohibited, but minification that only reduces file size is allowed.

What the policy says

From Mozilla's add-on policies:

  • Mozilla needs the source code before transpiling, minification or other machine generation.
  • Submissions must include instructions for reproducing the build. Missing this leads to rejection or blocking.
  • Obfuscated code, and code that hides what its functionality does, is prohibited.
  • Minification intended to reduce file size is allowed.
  • Add-ons must be self-contained, and loading remote code for execution is not allowed.
  • Reviewers may ask a developer to refactor code that they cannot review.
  • Source code is reviewed by an administrator and is not redistributed.

Why this matters for supply chain

Review is only as good as what reviewers can read. Requiring original source plus a reproducible build is a way to check that the shipped package matches the source. It also makes it harder to hide a payload in a generated bundle.

Chrome's store has a similar rule on obfuscation. Its policies prohibit obfuscation and allow minification. For more on that side, see the remote code rule.

What it does not do

Mozilla's page says policies guide human review and other assessments. That is not the same as a guarantee that every add-on is safe. A well written, readable add-on can still be built to misuse its permissions, and a clean version can be followed by a bad update. Policy compliance is a floor, not a seal. The firefox policies overview covers what users can and cannot rely on.

As a user

  • Prefer add-ons whose source is public and whose maintainers respond to issues.
  • Treat a long list of permissions as the main signal, whatever the review status.
  • Check the release history for sudden changes in ownership or purpose.

As a developer

  1. Keep your build reproducible and document it in a README that a reviewer can follow.
  2. Pin dependency versions and commit the lockfile.
  3. Do not minify in ways that hide logic, and never obfuscate.
  4. Scan your dependencies before every release, since the reviewer reads your code but may not catch a vulnerable library.

Common mistakes

Developers submit a bundle without the original source, or with build steps that only work on one machine. Reviewers then have to ask again and the release slips. Test your build instructions on a clean machine before submitting, and keep the output identical to what you ship.

Quick check

Is minified code allowed in Firefox add-ons?

Yes, when it is minification meant to reduce file size. The source and build instructions must be supplied so reviewers can read the original.

Can an add-on download and run code from a server?

No. Mozilla's policies say add-ons must be self-contained and loading remote code for execution is not allowed.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.