TL;DR: Chromium exposes multiple extension installation paths, including user installs, policy-based loads, registry entries, and component extensions, and the browser treats each differently based on ManifestLocation and location rank, according to Island. That distinction matters because extension provenance changes visibility, privilege, and control, making browser governance a security issue rather than a simple user-experience setting.
At a glance
What this is: Chromium distinguishes extension source locations and uses that classification to decide visibility, override order, and privilege treatment.
Why it matters: IAM and security teams need to treat browser extensions as governed software assets because installation provenance changes what users can see, what administrators can control, and what the browser itself will trust.
Context
Chromium extensions are not all installed, visible, or governed in the same way. The browser distinguishes between user-installed extensions, unpacked developer loads, registry- or policy-based installs, and built-in component extensions, then applies different trust and management rules to each source.
That creates a browser governance issue, not just a user-experience issue. Where an extension comes from can determine whether it is visible in the standard management UI, whether it can be overridden, and whether it behaves like an ordinary add-on or a browser-integrated capability.
Key questions
Q: What breaks when browser extensions are reviewed without their installation source?
A: Teams lose the ability to distinguish user-installed code from policy-controlled, registry-loaded, or browser-integrated components. That matters because Chromium treats those sources differently for visibility, override order, and privilege. A flat inventory can look complete while still missing the browser’s actual trust hierarchy, which is where governance decisions are really made.
Q: Why do component extensions create governance risk for security teams?
A: Component extensions sit inside the browser’s own implementation layer, so they may be hidden from the normal extensions page and treated differently from ordinary add-ons. That means they can carry trust and privilege assumptions that are easy to overlook if governance focuses only on externally installed extensions.
Q: How should teams use extension precedence in browser control reviews?
A: They should verify which location rank wins when the same extension ID appears in more than one source, especially where policy and user-installed versions could conflict. Precedence determines which code path is active, so it is part of the control model, not just an implementation detail.
Q: What should IAM and security teams do when browser extensions are deployed by policy?
A: They should treat policy-deployed extensions as governed entitlements, confirm the business owner and deployment source, and review whether the policy path also changes visibility or override behavior. Policy install is not just distribution, it is a control decision with operational and trust implications.
Technical breakdown
ManifestLocation and extension provenance
Chromium records where an extension came from using the ManifestLocation enum. That source value is not cosmetic. It tells the browser whether the extension was user-installed, unpacked, policy-deployed, registry-loaded, or shipped as a component, and the browser uses that classification to decide how the extension should be handled. In practice, provenance becomes part of the trust model. Two extensions with similar functionality can receive very different treatment because one is considered part of the browser’s own distribution path while another is treated as externally supplied code.
Practical implication: Inventory extensions by origin, not just by name, so governance can distinguish browser-owned components from externally supplied add-ons.
Location rank decides which extension wins
Chromium assigns a rank to each location type so it can resolve conflicts when the same extension ID appears in more than one place. Higher-ranked sources, such as component and policy-controlled extensions, override lower-ranked ones, while user-installed extensions sit at the bottom of the hierarchy. This creates a deterministic precedence model, but it also means control authority is embedded in source type. If teams do not know which installation path is active, they may misunderstand which version, policy, or privilege set is actually in force.
Practical implication: Map extension precedence during reviews so policy and support teams can verify which source is truly controlling each extension ID.
Component extensions sit outside normal user control
Component extensions are built into Chromium itself even though they are implemented as extensions. They are typically hidden from the standard extensions page, loaded from the browser installation directory, and treated as internal implementation details rather than user-managed software. That matters because these extensions can carry extra privileges and do not follow the same update or verification path as ordinary add-ons. For defenders, this blurs the line between application code and extension code, which is exactly where browser governance gets harder.
Practical implication: Treat component extensions as part of the browser attack surface and include them in baseline hardening and review processes.
Threat narrative
Attacker objective: The objective is to gain durable browser-level execution or privileged extension behavior that is harder for users and defenders to see or replace.
- Entry occurs when an extension is introduced through a channel that users or administrators may not inspect closely, such as policy deployment, registry loading, or an unpacked developer path.
- Credential or privilege exposure follows when the extension is granted browser-integrated capabilities, hidden from normal UI views, or allowed to override lower-ranked installations.
- Impact emerges when governance teams assume all extensions are equivalent, leaving trusted browser functionality and externally supplied add-ons governed by different rules without clear oversight.
Breaches seen in the wild
- Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Browser governance now includes extension provenance. Chromium shows that extension location is a control signal, not just metadata. A user-installed add-on, a policy-controlled extension, and a browser component do not belong to the same trust class, even if they look similar in naming or function. For IAM and security teams, that means browser governance should be treated as an entitlement and supply chain problem at the same time.
Visible extensions are not the same as installed extensions. The article shows that standard management surfaces can hide component extensions and other source types. That means control coverage based on chrome://extensions alone can miss important browser behavior, especially where internal components or policy-installed code carry extra privileges. Practitioners should assume that browser inventory is incomplete unless it is tied back to the underlying profile and installation source.
Location rank is a governance policy in code. Chromium’s override order embeds a decision about which sources deserve precedence, which is effectively an access model for browser functionality. That matters because governance teams often focus on allowed versus blocked, while the browser also decides which source wins when identities collide. The practical conclusion is that browser control requires precedence awareness, not just allowlists.
Browser components create a shadow privileged layer. Component extensions are part of the browser but still behave like extensions, which makes them easy to misclassify in operational reviews. This is a browser governance gap, not a narrow Chromium detail, because similar embedded capabilities can exist in other enterprise software stacks. Teams should include browser-integrated components in privileged software review, not only externally installed add-ons.
Chromium extension provenance is a named governance gap. The useful concept here is extension source trust segmentation: different installation paths create different control expectations, but many teams still review all extensions as if they were equivalent. That assumption breaks down the moment policy, registry, or component paths enter the picture. Security teams should govern extension source classes separately and document the privileges attached to each class.
What this signals
Extension source trust segmentation: browser governance needs separate control classes for user installs, policy installs, registry loads, unpacked development builds, and browser components. Treating those sources as equivalent hides the real trust model and makes review, support, and incident response less accurate.
Chromium’s design shows why software inventory is not enough on its own. Security teams need source-of-install data and precedence data together, because what matters is not only what is present, but which source the browser will trust when two copies of the same extension ID compete.
For practitioners
- Inventory extension source classes Build an inventory that separates user-installed, policy-installed, registry-loaded, unpacked, and component extensions so reviews reflect actual provenance rather than a flat extension list.
- Review hidden browser components Inspect component extensions alongside normal add-ons, because they may not appear in the standard extensions UI and can carry browser-integrated privileges.
- Validate precedence for duplicate extension IDs Check which ManifestLocation rank is active when the same extension ID appears in more than one location, and confirm that the intended source is the one actually taking effect.
- Extend browser governance to the profile store Use profile data such as Secure Preferences to verify what is installed, where it came from, and whether the browser UI is hiding important source details.
Key takeaways
- Chromium shows that extension installation source changes how the browser trusts, ranks, and exposes code.
- Visible add-ons do not represent the full extension estate, because component and policy-based installs can sit outside the normal UI.
- Browser governance should separate extension source classes so teams can review provenance, precedence, and privilege with the right level of control.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API9 — Improper Inventory Management | Extension source tracking is an inventory and trust-classification problem for browser-delivered software. |
| Recommendation — Inventory browser extensions by installation source and verify which class the browser will actually trust. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Extension location rank changes which code path gains effective control in the browser. |
| Recommendation — Apply PR.AA-05 to review extension entitlements by source class and precedence, not just by display name. | ||
| CIS Controls v8 | CIS-5 — Account Management | Extension governance here is about who or what can retain active browser capability over time. |
| Recommendation — Use CIS-5 to maintain an accurate, source-aware registry of browser extensions and remove unapproved entries. | ||
| MITRE ATT&CK | TA0003; TA0004 — Persistence; Privilege Escalation | Persistent browser components and higher-ranked sources can preserve or elevate extension behavior. |
| Recommendation — Map browser extension abuse to TA0003 and TA0004 to prioritize controls over hidden or elevated extension sources. | ||
Key terms
- ManifestLocation: A Chromium enum that records where an extension was loaded from and how the browser should treat it. The source can indicate user installation, policy deployment, built-in browser code, or developer loading, and it directly influences trust, precedence, and visibility.
- Location Rank: Chromium’s ordering mechanism for extension source types when the same extension ID appears in more than one place. Higher-ranked sources override lower-ranked ones, so rank becomes part of the browser’s effective control model.
- Component Extension: A browser extension that is treated as part of Chromium itself rather than as a normal user-installed add-on. It may be hidden from standard management views and can receive special privileges, which makes it important to include in governance and inventory processes.
- Browser Governance: The policy and control layer that manages how credentials, sessions, extensions, downloads, and authentication challenges behave inside the browser. It turns the browser from an unmanaged endpoint into part of the identity boundary, which is increasingly necessary for SaaS and privileged web access.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to the broader governance patterns that now show up in browsers, pipelines, and automated systems.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org