# Firefox Addon Policy Check

> Scans a Firefox WebExtension/add-on codebase for likely violations of Mozilla's Add-on Policies — permissions scope, remote code loading, CSP relaxation, data collection & consent (manifest data_collection_permissions), monetization rules (ads, affiliate links, crypto miners), source/obfuscation requirements, and "No Surprises" feature disclosure. Use whenever someone is building, reviewing, or about to submit a Firefox extension to addons.mozilla.org (AMO) and wants a policy/compliance/review-readiness check, or wants to know if their extension might get rejected or blocked — even without the word "policy," e.g. "will AMO reject this," "check my manifest.json," "audit my extension for Mozilla compliance." UNOFFICIAL, THIRD-PARTY HEURISTIC TOOL, NOT BUILT OR ENDORSED BY MOZILLA — always say so, before running it and in the report, and make clear a clean scan is NOT a guarantee of Mozilla approval.

- Skill: `mozilla/firefox-addon-policy-check` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add mozilla/firefox-addon-policy-check`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mozilla/firefox-addon-policy-check/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: mozilla (https://skillmd.com/u/mozilla)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mozilla/firefox-addon-policy-check

---


# Firefox Add-on Policy Check (unofficial)

## Say this up front, every time

Before doing anything else, tell the user in your own words:

> This is an unofficial, third-party check I'm running — it isn't built,
> reviewed, or endorsed by Mozilla. It looks for patterns that commonly trip
> up Mozilla's [Add-on Policies](https://extensionworkshop.com/documentation/publish/add-on-policies/),
> but it can't see your AMO listing text, your actual submission, or apply
> human judgment the way a Mozilla reviewer does. A clean result here does
> **not** mean Mozilla will approve the add-on — only Mozilla's own review
> process can determine that.

Repeat the substance of this at the end of the report too (see the template
below). Don't relegate it to a footnote — it belongs at the top and the
bottom, in plain language, not just in this skill's own instructions.

## What this skill is checking against

`references/policy-checklist.md` holds the actual policy text, organized by
the same section numbers Mozilla uses (1. No Surprises, 2. Content, 3.
Submission Guidelines, 4. Development Practices, 5. User Scripts, 6. Data
Collection and Transmission, 7. Monetization, 8. Security/Compliance/
Blocking), plus a note next to each clause about what a codebase scan can and
can't actually verify. Read it before writing the report so citations are
accurate rather than paraphrased from memory — Mozilla revises this document,
and if the user pushes back on a citation, the honest answer is "check the
live page," not "trust my memory of it."

## How to run the check

1. **Find the extension root.** Look for `manifest.json`. If the user pointed
   you at a folder, `manifest.json` is usually at its root or one level down
   (e.g. `src/`). If you can't find one within a couple of levels, say so and
   ask — don't guess at a path or assume it's a Firefox extension if there's
   no manifest.

2. **Run the scanner.**
   ```bash
   python3 <skill_dir>/scripts/scan_addon.py <extension_root> --json
   ```
   This does a fast pass over the manifest and source files for the patterns
   listed in `policy-checklist.md` — things like `<all_urls>` permissions,
   `unsafe-eval` in the CSP, remote `<script src>` tags, `eval`/`new
   Function`, outbound network calls near sensitive-looking data, known
   crypto-miner strings, affiliate-tag-looking URL rewrites, ad-like DOM
   injection, missing/malformed `data_collection_permissions`, and
   minified-looking first-party code. It emits JSON findings with a
   `policy_section`, `severity` (`review` or `info`), file/line, and message.
   It always exits 0 — findings are prompts for a human to look, not a
   pass/fail verdict.

3. **Read the findings and reason about them, don't just relay them.** The
   scanner is regex over text; it doesn't understand what the code is *for*.
   A `fetch()` call next to a browsing-history read might be the add-on's
   entire stated purpose (a history-sync tool, say) — completely fine — or it
   might be an undisclosed data leak. Open the flagged file, look at the
   surrounding code and at the manifest's description/name, and decide which
   findings are worth surfacing to the user versus clearly benign in context.
   It's fine — expected, even — to drop findings that are obviously fine once
   you've looked, and to add your own observations the regex-based scan
   wouldn't catch (e.g. actually reading whether the listing description
   matches what the code does, which nothing here can automate).

4. **Write the report using this structure:**

   ```markdown
   # Unofficial Firefox Add-on Policy Check

   > Not affiliated with or endorsed by Mozilla. Heuristic pattern-matching
   > only — a clean result is not a guarantee of AMO approval. See Mozilla's
   > actual policy: https://extensionworkshop.com/documentation/publish/add-on-policies/

   ## Summary
   [1-3 sentences: overall shape of what was found]

   ## Findings worth reviewing
   [Group by policy section number. For each: what was found, the file/line,
   the relevant clause in your own words (grounded in policy-checklist.md),
   and a concrete suggestion — not just "this might be a problem."]

   ## Informational notes
   [Lower-confidence or FYI items — things worth knowing but not necessarily
   action items.]

   ## What this scan can't tell you
   [Explicitly list the things that need a human/Mozilla reviewer: whether the
   AMO listing description matches the actual functionality, whether a consent
   UI is well-designed and unmissable, whether third-party library source
   links were actually provided to reviewers, legal compliance in the user's
   jurisdiction, and anything else genuinely outside what code inspection can
   verify.]

   ---
   Again: this is an unofficial check, not a Mozilla review. When in doubt,
   read the policy yourself or ask an AMO reviewer — https://extensionworkshop.com/documentation/publish/add-on-policies/
   ```

5. **If findings are heavy on `data_collection_permissions` gaps**, mention
   the Nov 3, 2025 requirement (new extensions must use Firefox's built-in
   consent system or an equivalent custom flow) and point to
   `references/policy-checklist.md` §6 for the exact taxonomy keys
   (`personallyIdentifyingInfo`, `browsingActivity`, `technicalAndInteraction`,
   etc.) so the user isn't left guessing what to put in the manifest.

6. **Offer to re-run after fixes.** This is the kind of thing people iterate
   on — flag a few things, they patch the manifest or code, they'll likely
   want a re-scan.

## Why the disclaimer discipline matters

Mozilla's actual reviewers apply judgment this scanner cannot: whether a
description is misleading, whether a consent flow is genuinely unmissable,
whether a "single primary function" claim is honest, whether source code
provided at submission actually reproduces the build. Telling the user "looks
clean" without the caveat risks them submitting with false confidence and
getting rejected or — worse — blocked after the fact for something a human
would have caught in ten seconds. The repeated disclaimer isn't legal
boilerplate for its own sake; it's the actual epistemic status of what this
tool can tell you.