Treat browser extensions as access-bearing non-human identities. Assign ownership, limit permissions, review update channels, and remove anything without a clear business purpose. The control goal is not only preventing malware, but also preventing a trusted add-on from becoming a persistent data path into SaaS, meetings, and browser-based workflows.
Why This Matters for Security Teams
Browser extensions sit in a difficult middle ground: they are not traditional service accounts, yet they often hold the same practical power to read mail, inspect SaaS pages, capture tokens, or move data between browser-based workflows. That makes them access-bearing NHIs that must be governed like any other identity with standing privilege. The risk is amplified because browser ecosystems encourage “install first, assess later,” while attackers and careless vendors can turn a helpful add-on into a durable data exfiltration path.
Security teams should treat extension governance as part of identity governance, not just endpoint hygiene. The issue is not only malicious extensions. A legitimate extension with broad permissions, unclear ownership, or an opaque update channel can become an unintended control bypass for SaaS data. NHIMG research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a useful warning sign for adjacent browser-mediated access paths as well; see The State of Non-Human Identity Security and the broader lifecycle guidance in Ultimate Guide to NHIs. Current guidance also aligns with the access-control principles in NIST Cybersecurity Framework 2.0 and the identity-focus areas in OWASP Non-Human Identity Top 10.
In practice, many security teams encounter extension abuse only after a trusted add-on has already become part of everyday access paths rather than through intentional review.
How It Works in Practice
Practical governance starts with inventory. Teams need a complete list of approved extensions, their business owners, the SaaS systems they can reach, and the exact permissions they request. That inventory should be tied to RBAC and ZTA principles: the extension may be installed on an endpoint, but it should not inherit broad trust just because the browser session is authenticated. Use the same discipline you would apply to service accounts and API tokens, as described in Top 10 NHI Issues and the lifecycle controls in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.
Then control the extension supply chain. Require named ownership, review release notes, pin approved versions where feasible, and remove extensions that do not have a clear business purpose. For high-risk use cases, restrict extensions to managed browsers, segment SaaS access by business function, and block access to sensitive applications unless the extension is explicitly approved. Where possible, use allowlists rather than broad category blocks. That matters because browser extensions frequently interact with browser session state, which means a weakly governed add-on can act like a shadow integration even when the SaaS platform itself is well secured.
- Assign an accountable owner for every approved extension.
- Review requested permissions against actual business need.
- Limit install sources and update channels to trusted paths.
- Reassess extensions after browser, SaaS, or policy changes.
- Remove extensions that are unused, duplicated, or unjustified.
For auditability, log extension installs, permission changes, and browser-policy exceptions, then correlate that telemetry with SaaS access logs and endpoint events. That gives investigators a way to distinguish normal browser-mediated activity from identity misuse. These controls tend to break down in bring-your-own-device environments because the browser itself is no longer fully managed and extension drift becomes difficult to detect.
Common Variations and Edge Cases
Tighter extension control often increases user friction and support overhead, so organisations have to balance access speed against exposure. That tradeoff is real in environments where workers rely on specialised browser add-ons for CRM, conferencing, or document workflows. Best practice is evolving here, but the general direction is clear: approve only what is needed, observe what it does, and remove everything else. There is no universal standard for how much browser telemetry is enough, so policy should be risk-based rather than purely technical.
One edge case is developer tooling. Extensions used for debugging, testing, or automation often require broader permissions than ordinary productivity tools, which makes them especially important to isolate from production SaaS accounts. Another case is AI-enabled extensions, which may capture page content and transmit it to external services; those should be reviewed as data-processing components, not as convenience tools. The same logic applies to vendor-installed extensions distributed through managed support programs. Even when the business relationship is legitimate, the extension still needs ownership, scope limits, and periodic reapproval. See Ultimate Guide to NHIs — Key Challenges and Risks and the breach patterns in Salesloft OAuth token breach. The operational lesson is simple: if an extension can read or reshape SaaS data, it deserves the same governance discipline as any other access-bearing NHI.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Browser extensions often rely on long-lived access that should be rotated or revoked. |
| NIST CSF 2.0 | PR.AC-4 | Extension permissions should follow least-privilege access control. |
| NIST Zero Trust (SP 800-207) | AC-6 | Extensions should not inherit broad trust from an authenticated browser session. |
Inventory extension credentials and revoke any standing access that is no longer essential.
