For the complete documentation index, see llms.txt. Prefer markdown by appending .md to documentation URLs or sending Accept: text/markdown.

Overview

Extension security centers on least-privilege permissions, a shared web session, and isolating content scripts from page JavaScript.

The browser extension is a client with a smaller auth UI surface: it shares the web app session instead of reinventing sign-in. Most of its risk sits in permissions, host access, and content scripts.

This section is a security playbook - what to allow in the manifest, how session sharing stays safe, and what to double-check before you submit to the stores.

Be mindful

Security is not a one-time setup. Revisit these practices whenever you add permissions, content-script matches, messaging handlers, or store listing claims.

Security model

Defense in the extension is permission- and isolation-focused. The API still owns authorization:

LayerWhat it protectsWhere it lives
Shared sessionUsers sign in once on the web; extension reuses the cookieBetter Auth + cookies / host permissions
Trusted originsOnly your extension id can participate in auth redirectsBetter Auth trustedOrigins
Least privilegeManifest grants only what you needwxt.config.ts manifest
Content script isolationPage JS cannot read extension privileges directlyIsolated world + narrow matches
Messaging boundariesPopup / background / content treat messages as untrusted inputTyped WXT messaging
API enforcementMutations still go through protected Hono routesShared API (see Web security)

Server-side rules (middleware, Zod, webhooks, secrets) stay in Web security. The extension should call that API - not embed secret keys in the bundle.

Each of these topics is covered in more detail in the following guides:

How is this guide?

Last updated on

On this page

Ship your startup everywhere. In minutes.Try TurboStarter