Notifications
Clear all
Topic starter
02/08/2026 12:03 pm
TL;DR: Browser extensions can be hijacked, over-permissioned, or updated with malicious code to exfiltrate session data and sensitive user activity, according to Island’s analysis of the Cyberhaven incident and broader Chrome extension compromise. Consumer browser assumptions no longer fit enterprise risk, especially where identity, session protection, and admin workflows intersect.
NHIMG editorial — based on content published by Island: Browser Extensions in the Enterprise
Questions worth separating out
Q: What challenges do browser extensions pose to enterprise security?
A: Browser extensions bridge a gap in security controls, as they may not be monitored effectively under current IAM practices.
Q: Why do browser extensions increase identity and access risk?
A: Browser extensions sit inside the authenticated browser session, so they can observe or influence access without a separate login.
Q: What breaks when extension permissions are too broad?
A: Broad permissions let an extension see and sometimes alter far more browser activity than its stated function needs.
Practitioner guidance
- Centralise extension approval and risk scoring Build an allowlist and review process that evaluates extension permissions, developer provenance, version history, and behaviour changes before deployment across the enterprise browser estate.
- Protect browser session artifacts Apply controls that encrypt cookies and session tokens in the browser layer so a compromised extension cannot freely exfiltrate authenticated session data.
- Secure extension publishing workflows Require step-up MFA, approval workflows, and privileged-access review for any employee who can access the Chrome Web Store or publish browser extensions.
What's in the full article
Island's full blog covers the operational detail this post intentionally leaves for the source:
- Risk-scoring logic for extension versions, permissions, and publisher history across the Chrome Web Store
- Browser policy patterns for allowlists, automatic installation, and selective disablement on sensitive applications
- Controls for securing Chrome Web Store publishing workflows, including MFA challenges and approval steps
- Deployment options for extending the same governance model to consumer browsers already used inside the enterprise
👉 Read Island's analysis of browser extension risk in the enterprise →
Browser extensions in enterprise environments: are controls keeping up?
Explore further
02/08/2026 1:09 pm
Browser extensions have become an identity-adjacent control plane. Once a browser session is authenticated, an extension can inherit enough trust to interfere with tokens, cookies, and web requests. That means browser governance is no longer just endpoint hardening, it is session governance tied to identity assurance and application access. Practitioners should treat extension permissions as part of the access model, not a convenience layer.
A question worth separating out:
Q: Who should be accountable for malicious extension publishing workflows?
A: Accountability should sit with the teams that control privileged browser publishing access, identity governance, and endpoint policy. If an employee can publish or modify an extension, that workflow needs the same level of review, auditability, and approval as any other high-risk identity action. Browser security is not separate from PAM and IAM.
👉 Read our full editorial: Browser extension risk in the enterprise demands stronger control models
