Browser and extension security: the endpoint everyone forgot

For most knowledge workers the browser is the operating system now - mail, documents, finance, code review and administration all happen inside it. Which makes it odd that endpoint programmes scrutinise installed software carefully and treat browser extensions as a personal preference.

What an extension can actually do

An extension with permission to read and change data on all sites can, in practice, see everything you see and act as you: read the contents of your inbox, capture what you type into a form, read session tokens, and modify pages. That is a broader capability than most installed applications have.

Users grant it routinely, because the permission prompt appears at the moment they want the functionality and the wording is not alarming.

The supply chain problem

• Extensions update silently. A benign extension can become malicious in an update without any user action.
• Popular extensions get bought. There is an established pattern of acquisition followed by monetisation through data collection or injected content.
• Developer accounts get compromised, pushing malicious updates to an existing install base.
• Store review is not a guarantee - malicious extensions reach official stores regularly.

The consequence worth internalising: reviewing an extension at install time tells you about the version you reviewed. The risk is in the version that arrives next month.

Why this connects to session theft

Modern attacks increasingly steal the session rather than the password, and the browser is where sessions live. An extension with page access, or malware reading the browser's token storage, obtains an authenticated session that survives a password reset. If you have deployed phishing-resistant MFA, the browser becomes the remaining soft target.

What actually works

1. Manage the browser. Enterprise browser policy is supported on every major platform and is usually already available through your existing management tooling - it is frequently just unconfigured.
2. Allowlist extensions rather than blocklisting. A blocklist is a losing race; an allowlist with a fast approval route is manageable.
3. Review requested permissions during approval, not just the extension's purpose. An extension needing all-site access to change a colour scheme is a bad trade.
4. Force updates and disallow developer mode, which is a common bypass.
5. Separate profiles - work profile signed into corporate identity, personal browsing elsewhere. This is the cheapest structural control available.
6. Bind sessions to a managed device so a stolen token replayed elsewhere fails.

The approval route matters

Allowlisting only works if requesting an addition is fast. If approval takes two weeks, people work around it - using a personal browser for work, which is strictly worse than the extension you were worried about. Publish the approved list, respond quickly, and explain refusals.

What to check now

Most organisations have never looked. Pull an inventory of installed extensions across the fleet - management tooling can usually report it - and sort by permission scope rather than by name. The result is typically a small number of extensions with all-site access that nobody approved and nobody can justify.

Key takeaways

• An all-site extension sees everything you see and can act as you.
• Install-time review says nothing about next month's update.
• Allowlist with a fast approval route, or people route around it.
• Inventory by permission scope - that is where the surprises are.