A web extension is a small package of code that a browser loads alongside pages in order to change or add to how the browser behaves. Extensions are ordinary web technology — HTML, CSS and JavaScript — granted privileges that a normal page does not have.
01How an extension is built
Every extension is described by a manifest, a structured file that declares its name, version, the permissions it requests, and which of its scripts run where. The manifest is the contract the browser enforces; anything not declared in it is not available at runtime.
Most extensions combine a few standard parts. Content scripts are injected into matching pages and can read and modify the page's DOM, though they run in an isolated context rather than sharing the page's own script environment. A background script or service worker holds logic that must persist across tabs and outlive any single page, and is event-driven rather than continuously running. User interface surfaces include the toolbar popup, an options page, and in some cases panels alongside the browser's own developer tools. Communication between these parts happens over an explicit messaging API rather than shared memory.
The APIs themselves are broadly aligned across browsers under a common extension model, which makes a single codebase largely portable. Alignment is not identity, though: capabilities, manifest details and store requirements still differ per browser, and cross-browser support means real testing rather than assumption.
02The permission model
Extension permissions are the whole security story, and they are unusually consequential because of what an extension can be granted.
Permissions fall into two rough groups. API permissions unlock browser capabilities such as reading tabs, managing downloads, modifying network requests or accessing storage. Host permissions name the sites the extension may act on, and a permission covering all sites is effectively read and write access to every page the user visits, including banking, email and internal systems.
Because that access is so broad, several practices matter. Request the narrowest host pattern that works, and prefer permissions granted at the moment of use over permissions granted at install. Treat any extension with wide host access as part of the trusted computing base of the machine. Note also that an extension can change ownership after installation and update itself silently through the same channel, so an extension that was safe when installed is not guaranteed to remain so.
03Practical use and support implications
For users, the useful habits are simple: install only from the browser's official store, review what an extension asks for at install and again after an update, and remove anything unused rather than leaving it dormant with its permissions intact. Enterprise environments can control this centrally through policy, allowing an approved list rather than relying on individual judgement.
For anyone supporting a web application, extensions are a common and under-diagnosed source of reports. Content scripts run before and alongside application code and can block requests, rewrite the DOM, or inject conflicting styles. When a defect cannot be reproduced, asking the reporter to retry in a clean profile with extensions disabled separates an application bug from a local interference problem faster than any other single step.