Manifest V3 is Google’s updated browser extension platform that changes how extensions declare permissions, run background logic, and handle code execution. It replaces persistent background pages with service workers and blocks remotely hosted code, creating a more constrained but more security focused environment for extension developers.
Expanded Definition
Manifest V3 is the browser extension platform model that governs how extensions declare permissions, execute logic, and interact with the page and browser runtime. Its main security shift is architectural: extensions are pushed away from always-on background pages and toward event-driven service workers, with tighter limits on remote code execution and dynamic behaviour.
That boundary matters because extension capability is still powerful even when the runtime is more constrained. Manifest V3 does not make extensions harmless; it changes which behaviours are allowed by default and which must be expressed up front in the manifest. For developers and reviewers, the practical distinction is between static, reviewable extension logic and extension designs that relied on persistent background state or code loaded after publication. The OWASP Non-Human Identity Top 10 is a useful companion reference when an extension depends on machine credentials or tokens, because the extension can become a trust boundary for non-human access even though the platform itself is not an identity standard.
One common misunderstanding is treating Manifest V3 as a content policy only. It is also a permission and execution model, which means it affects security review, runtime observability, and what kinds of automation are still possible inside an extension.
Examples and Use Cases
Manifest V3 shows up anywhere extension developers need browser-level automation under tighter security constraints. The term is most useful when discussing how an extension is built, reviewed, or governed rather than when describing a generic browser add-on.
- An enterprise browser extension uses a service worker to react to tab events instead of holding a persistent background page open.
- A security team reviews an extension’s declared permissions to understand whether it can read pages, modify requests, or inject scripts.
- A developer refactors an older extension because remote code loading is no longer an acceptable design pattern under the newer platform model.
- A browser governance team uses the manifest as a control point to compare requested capabilities against business need.
- An automation extension that handles API tokens or session data must be evaluated as a machine-access component, not just as a UI helper.
The main tradeoff is capability versus control: the tighter model improves reviewability and reduces some abuse paths, but it can also break extensions that depended on long-lived background execution or late-bound logic.
Security Implications
Manifest V3 reduces certain abuse patterns by constraining how extension code is delivered and when it runs, but it does not eliminate extension risk. An extension with broad permissions can still observe browsing activity, alter traffic, or mediate access to sensitive web applications.
Misunderstanding the model often leads to two failures. First, teams may assume the new platform version is secure by default and stop scrutinising permission scope. Second, developers may rebuild old behaviour in ways that preserve the same trust exposure, only with a different execution path. The security consequence is a larger attack surface than the organisation expects, especially if extension logic touches authentication flows, tokens, or internal web applications.
NHIMG research shows that 97% of NHIs carry excessive privileges, which is a useful warning for browser extensions that act on behalf of users or services: overbroad capability in non-human components tends to widen blast radius. If an extension is compromised, the result is usually not just a broken plugin but a path into browser sessions, web app data, or downstream machine access.
Domain and Governance Relevance
Manifest V3 matters in browser security governance because it changes what administrators, developers, and reviewers should expect from extension design. Governance now needs to focus less on whether an extension is merely installed and more on whether its declared permissions, event-driven behaviour, and code-loading model match the intended trust boundary.
For NHI-heavy environments, the relevance becomes sharper when extensions support automation, authenticated workflows, or service interactions. A browser extension that stores tokens, handles API calls, or brokers access for a team is participating in non-human identity and secret handling, even if the platform itself is not an identity product. That means inventory, permission review, and code provenance become part of machine-access governance. In practice, the most important question is whether the extension’s permitted behaviour is narrow enough for the role it plays in access and automation.
NHIMG’s Ultimate Guide to NHIs is a helpful reference when you need to connect extension governance to secrets, lifecycle control, and machine privilege. For platform-level security expectations, the OWASP Non-Human Identity Top 10 helps frame the risks that appear when extensions handle non-human access paths.
Risk and Threat Considerations
Manifest V3 reduces some extension abuse opportunities, but the subject still carries material risk because browser extensions can sit close to user sessions, web content, and sensitive automation flows. The main exposure is overprivileged or poorly reviewed extension logic that can be misused, compromised, or trusted too broadly.
Failure mechanism: Risk materialises when an extension requests more permissions than it needs, preserves access to sensitive pages, or reintroduces unsafe behaviour through alternative code paths. Attackers and malicious extension authors benefit from that trust because extension privileges can be used to read data, alter page content, or access authenticated workflows.
Impact: The result can be browser session theft, data exposure, compromised web application actions, or indirect access to machine credentials and tokens handled by the extension. In managed environments, one weak extension can become a repeatable trust-breaker across many users.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | Manifest V3 constrains extension behaviour through configuration and allowed code patterns. |
| CIS 6 — Access Control Management | Extension permissions function as access grants to browser data and actions. | |
| CIS 8 — Audit Log Management | Extension activity and permission use need visibility for detection and review. | |
| Recommendation — Review extension configurations and block unsupported capabilities that expand browser attack surface. Limit extension permissions to the minimum access required for the approved use case. Log and monitor extension behaviour that can affect sensitive browsing or authentication flows. | ||
| MITRE ATT&CK | T1176 — Browser Session Hijacking | Browser extensions can interfere with or abuse active browser sessions. |
| Recommendation — Hunt for extension behaviours that can capture or manipulate authenticated browser sessions. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Extensions that handle tokens or API keys become part of non-human credential handling. |
| Recommendation — Treat extension-handled tokens and secrets as NHI assets with explicit lifecycle controls. | ||
