Auditing Browser Extension Trust

Auditing browser extension trust: what another page can reach through the extension

A browser extension is dangerous where a web page it does not trust, or another installed extension, can drive one of its privileged capabilities: a host-scoped fetch that carries the user's cookies, a chrome-namespace API, or a DOM write in a content script that runs with the extension's reach. The bug is almost always a message boundary that verifies too little: an external handler that checks the calling domain but not that a trusted script is calling, or a content-script-to-background channel that trusts any sender. You audit it by resolving, per privileged sink, whether every path that reaches it validates the sender identity and origin and whether the permission it uses is scoped to what the extension needs. Stay on the extension's trust boundary; the web-page DOM sink taxonomy belongs to the client-side DOM skill.

When to use

• You are reviewing a browser-extension manifest, its background service worker, and its content scripts.
• The extension exposes an external message handler, a cross-context channel, or web-accessible resources.
• You want to know what an untrusted page or extension can reach through the extension's privileges.

Scope check

Audit only extensions you own or are authorized to assess, and drive a message boundary only against an extension and profile in scope, a privileged handler acts on the real browser session. Adjudicate on the manifest and the handlers. If you can't name the authorization, stop.

The loop

1. Resolve the permission scope and the sender checks first. Read the manifest for host permissions (a broad all-urls match versus an activeTab or a narrow host list) and for the external-connection surface, and read each message handler for what it validates about the sender. A privileged sink is only an attack surface when an untrusted caller can reach it and the permission it uses is broad enough to matter, so settle both before flagging.

2. Check the external message surface. Look for an externally_connectable configuration or an onMessageExternal handler that a web page or another extension can call, and check whether it verifies the origin and that the calling script is one it trusts. Verifying the domain but not the script, or matching origins with a wildcard, lets an untrusted page drive the handler.

3. Check the content-script-to-background channel. Look for a background message handler that performs a privileged action on a message from a content script without validating the sender, so any page's injected script can send the message and drive the action.

4. Check host permissions and web-accessible resources. Look for host permissions broader than the feature needs (all-urls where activeTab or a single host would do), granting mass cookie and page access. And look for a web_accessible_resources page that reads URL parameters and performs a privileged action or reflects them into its DOM, making the operation website-triggerable.

5. Check DOM sinks and the content-security policy. Look for an injected content script writing page-controlled data to an innerHTML-class sink, giving a universal cross-site-scripting with the extension's origin, and for a content-security policy that permits eval or remote script where the platform would otherwise forbid it.

6. Confirm and record. Confirm by showing an attacker-controlled web origin or an arbitrary extension reaches a privileged API, a host-scoped fetch, or a DOM sink without passing a sender-and-origin check. Kill the lead if the handler validates the sender id and origin against an allowlist, if the exposed function only reads and reaches no privileged sink, if the host permission is activeTab (user-gesture scoped) or a narrow host rather than all-urls, if the web-accessible resource takes no parameters and performs nothing privileged (mere exposure is not a bug), if the DOM write uses a text or attribute sink or a sanitizer or writes only an extension-controlled constant, or if the flagged eval permission is not actually present in the emitted policy. Record the entry point, the missing check, and the sink reached.

Where extension trust leaks

• Verifying the origin but not the script is the classic gap. An external handler that checks the calling domain yet not that a trusted script is calling lets an untrusted page on that domain drive it.
• A content script runs in an isolated world. Page JavaScript cannot call the extension without an exposed channel; an exposed function that only reads is not a sink, but one that acts on any sender is.
• Over-broad host permission is the amplifier. All-urls turns any reachable handler into mass cookie and page access; activeTab or a narrow host list keeps the blast radius small.
• A parameterized web-accessible page is website-triggerable. A resource that acts on URL parameters lets a website drive a privileged operation; one that takes no parameters and does nothing privileged is just exposed, not vulnerable.
• A content-script DOM write inherits the extension origin. Page-controlled data into an innerHTML-class sink is a universal cross-site-scripting; a text or attribute sink, or a sanitizer, kills it.

Worked example (a confirm and a kill)

Confirm. A background service worker handles an external message that names a URL and fetches it with the extension's host permissions, returning the response to the caller. The handler checks the message shape but not the sender, and externally_connectable matches all pages. Any web page posts the message and reads a cross-origin resource through the extension's privileges. Confirmed an unauthenticated external handler reaching a host-scoped fetch, high, remediation = restrict externally_connectable to trusted origins, validate the sender id, and scope the fetch to an allowlist.

Kill. The same handler validates sender.id against a small allowlist and externally_connectable lists only the vendor's own origins; a page from any other origin cannot reach it, and the host permission is a single named host, not all-urls. Killed, kill_reason = "the external handler validates the sender id and origin against an allowlist and the fetch is scoped to one host; no untrusted caller reaches a privileged sink."

Rationalizations to reject

• "We check the origin." -> Do you check that a trusted script is calling, not just the domain? Verifying the origin but not the caller lets any page on that origin drive the handler.
• "Content scripts are isolated." -> They are, until you expose a message channel; a handler that acts on any sender is the channel that defeats the isolation.
• "We need broad host access." -> Would activeTab or a named host do? All-urls turns every reachable handler into mass cookie and page access; scope it to the feature's need.
• "It is just a web-accessible file." -> Does it read URL parameters and do something privileged? A parameterized resource is website-triggerable; a passive file is only exposed.
• "The content script writes to the page." -> With what sink? Page-controlled data into innerHTML is a universal cross-site-scripting; confirm it is a text or attribute sink or is sanitized.

Executing this in practice

You need the manifest (host permissions, externally_connectable, web_accessible_resources, and the content-security policy), the background handlers and what each validates about the sender, the content scripts and their DOM writes, and the map from each entry point to the privileged sink it can reach. For each sink, decide whether an untrusted caller can reach it without a sender-and-origin check and whether the permission it uses is scoped. Reading the manifest tells you the surface; reading the handlers tells you what an untrusted caller can drive.

Related

• auditing-electron-ipc-trust - the desktop-app sibling with the same untrusted-content-to-privileged- capability shape, across the Electron preload bridge rather than the extension message boundary.
• auditing-editor-extension-workspace-trust - the editor-extension sibling, where the untrusted source is a cloned repository rather than a web page or another extension.
• testing-client-side-dom-vulnerabilities - owns the web-page DOM sink taxonomy this skill references for the content-script injection shape; the trust boundary (isolated world, host permissions) is unique here.
• FINDING-SCHEMA.md - source = an untrusted web origin or another extension, sink = a privileged extension API or DOM sink, evidence = the reachable entry point, the missing sender-and- origin check, and the privilege it reaches.