Under a work rule, I can only install browser extensions after checking their permissions and documenting why I need them. I currently have 7 installed, but I’m unclear whether “least privilege” applies to extensions the same way it does elsewhere. What rule do you use before installing one, and what warning signs make you stop?
Start by removing or disabling anything you have not used in the last month. For extensions, least privilege applies to both permissions and time: keep access only while there is a current business need. My default would be a personal allowlist, meaning no extension gets installed unless the browser cannot already do the job and the benefit is worth the added attack surface.
I would stop if it requests “read and change all data on all websites” for a narrow feature, has no clear publisher or privacy policy, sends browsing data to external servers without a solid reason, or appears abandoned. A sudden ownership change, major permission increase, or unexplained change in purpose deserves another review too. Install-time checking is not enough because extensions update automatically.
Where possible, grant access only on specific sites or only when clicked. Document the task, required sites, permissions, publisher, and review date. That turns the rule from paperwork into an actual control, and it makes periodic cleanup much easier.
The extension count is the wrong metric.
Least privilege should follow the data you expose. A narrowly scoped extension used daily may be less concerning than a rarely used one that can inspect every page, including email, payroll, customer records, and internal tools. If your browser supports separate profiles, keep work browsing in a profile with only work-approved extensions. That limits the damage from extensions installed for shopping, media, or personal convenience.
I agree with @jeff that access should expire with the business need, but I would uninstall rather than leave old extensions disabled indefinitely. For extensions that remain, document which categories of company data they can encounter, not merely the permission wording. A strict allowlist makes sense for the work profile because it turns exceptions into deliberate decisions instead of slowly accumulating permanent access.
Don’t treat the initial permission check as permanent approval. Extensions update automatically, can change ownership, and may request broader access later, so a work allowlist should include periodic reviews and removal when the need ends.
Treat extensions as software, not browser settings.
For a work browser, I would use a strict allowlist, but the approval should cover the extension’s operating model, not merely its name and website permissions. An extension may have limited access to page content while still using browser APIs for cookies, downloads, clipboard data, authentication, or network requests. “Only on this site” is useful, but it does not necessarily restrict every capability the extension has.
Pay special attention to extensions that require a companion desktop application. If they use native messaging, the browser extension can communicate with software running outside the browser sandbox. That may be legitimate for password managers, signing tools, or device integration, but reviewing the extension permission prompt alone is not enough. The companion program needs the same software approval process as any other installed application.
I would push back slightly on removing something solely because it has not been used recently. Some legitimate work tools are needed only for quarterly reporting, certificate renewal, or a specific customer system. For those, the choice should be explicit: either install them for the task and remove them afterward, or approve them as infrequent persistent tools with a defined purpose. Usage frequency by itself does not measure exposure or necessity.
Browser synchronization is another easy hole in the process. If extension sync is enabled, signing into a work profile or replacement computer can restore extensions without a fresh review. A managed work profile should either disable extension sync or enforce the same allowlist through browser policy. Otherwise, the documented approval process can quietly be bypassed by the browser’s convenience features.
For sensitive systems, I would go further than site-level permission controls. Keep administrative consoles, payroll, finance, and similar systems in a managed profile with no optional extensions at all. A separate profile is useful for reducing routine exposure, although it should not be treated as a hard security boundary against malicious software on the same machine.
So the practical model is a small persistent allowlist, task-based installation for occasional tools, and separate approval for anything with a native component. Least privilege applies to extensions, but permission text is only one part of it. You need to account for browser APIs, companion software, synchronization, and where the extension is allowed to run.
If this is a rule you’re enforcing on yourself rather than something IT pushes through managed policy, the allowlist debate matters less than whether you’ll actually revisit the list. Self-documentation rots fast. You write down a solid reason in January, the extension quietly gains a permission in an update, and your paperwork still says ‘approved’ because nobody went back to compare. So whatever you decide, the review date @jeff mentioned is the load-bearing part, not the initial check.
@nanovision is right that the count is a distraction. Seven means nothing. I’d frame the core question OP asked more bluntly: yes, least privilege applies to extensions, and it applies harder than to normal software, because an extension lives inside the same session as everything you’re logged into. A desktop app that goes rogue has to work to reach your webmail. An extension with broad host access is already there.
Here’s the thing people miss when they get deep into permissions and native messaging: A lot of what you’d install an extension for, the browser already does, or could be had for a one line bookmarklet. Tab management, basic JSON viewing, color pickers, redirects, reader view. Before you document a reason, consider whether you need a third party in the loop. That cuts off more entries on the ‘list’ than any permission audit would, and it kills the entire risk of update entirely because there’s nothing to update.
One caveat on the ‘read and change all data on all websites’ panic: Yes, that prompt is terrifying for a narrow tool, but plenty of legitimate extensions ask for that permission due to Chrome’s permission model being coarse and the developer not having scoped their host permissions. It’s a signal, not a reason to delete. What tips me off is a combination of broad permissions and a vague publisher and network calls I can’t rationalize. Any two of three and I’m out.
My actual rule, if you want something short: Install only when the browser can’t do it and a bookmarklet can’t either, keep the work profile to a small, fixed set, and put a recurring calendar reminder to re-open each extension’s permission page. If you skip the last step, none of the previous hold for more than a few update cycles.
A strict allowlist can become a game of cat and mouse if no one takes responsibility for incoming requests. “Your request is pending” is not an acceptable response for a tool that someone needs to use to do their job. Personally, I would take an allowlist with a named approver and a viable exception process over either of those any day. Otherwise, I can only imagine the workarounds that people will use to get their jobs done, such as using personal browsers or pasting sensitive information into some random online converter. In short, those are not options that I would consider appealing.
That’s where I’d push back on @logictester3592one’s browser-or-bookmarklet test. Check built-in features first, sure, but I wouldn’t make “could be done with a bookmarklet” an automatic rejection. The proposed alternative deserves scrutiny too, rather than a free pass for not being an extension. Yes, least privilege applies: approve the access needed for a defined task. For your situation, I’d ask whoever owns the rule whether documenting the need actually authorizes installation or merely starts a review. Then ask what you’re supposed to use while waiting. An approval process should have an answer beyond “please remain productive without the thing you requested.”
Don’t turn “approved for someone” into “approved for everyone.” I’d take @0xdragon9’s named approver and make each approval specific to a job or task. A support team’s need for an extension does not justify installing it across accounting. Yes, least privilege applies, but an allowlist should be a menu of permitted tools, not a default installation bundle. Install from it as needed, with your own documented reason. “IT allows it” and “I need it” are separate checks.
An allowlist can create pressure to keep an extension approved once a workflow depends on it. I’d use approved extensions as needed, as @panda.linux suggests, but include a fallback in the justification for anything essential to your job. Least privilege should leave room to withdraw access, and I’d be wary of an approval that effectively becomes permanent because nobody has another way to finish the work.