Ban obfuscation, allow minification, and require the original source or a reproducible build. Obfuscation exists to hide what code does, which defeats review by people and tools alike. Minification reduces size and is harmless if reviewers can see the source it came from.
What three directories say
Chrome Web Store. The review documentation says obfuscation is disallowed because it increases the complexity of validation. Minification is allowed, though it can also make review harder. It suggests submitting code as authored where possible and structuring it so others can understand it. It also notes that more code means more work to verify, which can lengthen review.
Mozilla add-ons. Add-ons may contain transpiled, minified or machine generated code, but Mozilla needs to review a copy of the source before those steps, with instructions to reproduce the build. Dependencies must be included in the source package or come from official package managers during the build, and unsupported build tools are not accepted. Obfuscated code, or code that hides the purpose of the functionality, is not allowed. Failure to provide source results in rejection or blocking.
WordPress.org. Guideline 4 says code must be mostly human readable. Techniques similar to p,a,c,k,e,r obfuscation, minifier name mangling or unclear naming such as random variable names are not permitted, because they force future developers over an unnecessary hurdle and are a common vector for hidden malicious code. Developers must provide public, maintained access to source code and build tools.
Obfuscation versus minification
| Property | Obfuscation | Minification |
|---|---|---|
| Purpose | Hide logic | Reduce size |
| Reviewer impact | Severe | Moderate |
| Typical rule | Banned | Allowed with source |
| Reversible by tooling | Often not | Mostly yes |
Writing your own rule
- State plainly what is banned and what is allowed, with examples.
- Require the pre build source and build instructions with each submission.
- Rebuild from source in review and compare the output to the submitted package. A mismatch is a finding.
- Limit dependencies to those pulled from official registries during the build.
- Reject packages that load and run code from outside the package after install. Chrome's Manifest V3 guidance says all logic must be part of the extension package, with sandboxed iframes as the stated exception for remote code. WordPress guideline 8 also bars sending executable code through third party systems.
- Document the appeal path when a reviewer cannot read a file.
Why the rebuild step matters
A source submission that does not match the shipped package is worse than none, because it gives false comfort. Reproducible builds close that gap. They also help your own incident response: when a plugin is reported, you can read exactly what it does.
Honest limits
Readable code is not safe code. A clean looking plugin can still do harm, and a sound minified one can be fine. The rule reduces the cost of review and removes one common hiding place. It is not a substitute for permission limits or sandboxing.
Quick check
Is renaming variables to short names obfuscation?
Standard minification does this and is generally allowed where source is provided. Names chosen to deceive or make code unreadable beyond ordinary minification, as in the WordPress guideline, are treated differently.
Can a plugin download code after install?
Under the Chrome and Mozilla rules described here, no, with narrow exceptions such as sandboxed iframes in Chrome. Config data may be fetched, but not executable logic.
Safeguard works on the dependency and release gate side of this, with SBOM and dependency scanning and policies for builds. Try the free scan.
Sources
- Chrome Web Store review process
- Add-on Policies, Firefox Extension Workshop
- Detailed Plugin Guidelines, WordPress Plugin Handbook
- Improve extension security, Chrome for Developers
Last reviewed: 19 October 2026.
