> ## Documentation Index
> Fetch the complete documentation index at: https://extension.js.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Extension security checklist

> Reduce extension attack surface before release with a repeatable security review. Covers least privilege, constrained runtime access, and input validation.

Your extension can fail store audits and internal reviews for a few recurring reasons. Permissions drift wider than your features need. Content scripts trust page context unsafely. Web-accessible resources (WAR) expose internals to arbitrary origins. Message handlers act on unverified senders.

Run this checklist before every release.

## Security review capabilities

| Area                                    | What this helps you verify                                                |
| --------------------------------------- | ------------------------------------------------------------------------- |
| Permissions scope                       | Requested capabilities are minimal and intentional                        |
| Content-script safety                   | Page-context behavior avoids unsafe injection patterns                    |
| WAR (web-accessible resources) exposure | Only required assets are externally readable                              |
| Message boundaries                      | The extension validates privileged actions and checks senders             |
| Release hygiene                         | Continuous integration (CI) and dependency checks catch regressions early |

## Manifest and permissions

* Request only permissions you need.
* Avoid broad host permissions unless required.
* Prefer optional permissions for non-core capabilities.
* Re-check `web_accessible_resources` scope after feature changes.

## Content scripts

* Default to the isolated world (the sandboxed execution context) unless you strictly require MAIN world access to the page's JavaScript environment.
* Keep selectors and DOM mutations scoped to known targets.
* Sanitize untrusted page data before rendering or storing.
* Avoid injecting executable strings into page contexts.

## Web-accessible resources

* Keep WAR entries explicit and minimal.
* Avoid wildcard `resources: ["*"]` patterns.
* Restrict `matches` to required domains.
* Use runtime URL helpers (`runtime.getURL`) for asset access.

## Messaging and data flow

* Validate message payload shape before processing.
* Verify sender context for privileged operations.
* Avoid exposing privileged operations directly to page scripts.
* Keep boundary modules for content/background communication.

## Build and release hygiene

* Run lint, type checks, and tests in CI.
* Review production bundle output for unexpected artifacts.
* Keep dependencies updated and remove unused packages.
* Rotate secrets and keep sensitive values out of client-exposed env vars.

## Common high-risk anti-patterns

* `host_permissions` with broad wildcards that are not feature-critical
* `web_accessible_resources` exposing broad globs to `<all_urls>`
* Message handlers that trust payloads without sender or schema checks
* Using MAIN-world scripts when you can use the isolated world instead

## Quick pre-release pass

1. Permission review
2. WAR review
3. Content script world review
4. Messaging validation review
5. CI green on target browser matrix

## Next steps

* Review [web-accessible resources](/docs/implementation-guide/web-accessible-resources).
* Review [Troubleshooting](/docs/workflows/troubleshooting).