Know Thy Extensions: Governing the Browser Attack Surface in the Enterprise
No ratings
Presented at BSidesAugusta 2026 by
A typical enterprise has hundreds to thousands of Chrome extensions running against its most sensitive systems, and little visibility into what those add-ons can actually do. An extension a single employee installs to "make Gmail nicer" may quietly hold permission to read cookies on every site the user visits. And "every site" includes your SSO, your secrets manager, your source control, your CRM. We flipped the default: an allow-list posture where new extensions must be requested, and an evaluation engine that decides each request, acts on the decision, and explains it in plain English to the person who asked. This talk walks through how we built it and what we learned. Evaluating a request means asking two different questions. The first is universal: a dangerous capability is dangerous no matter who installs it, and the engine checks for that like any scanner would. The second is the one a generic score structurally can't see — the environment the extension is running in. An extension that reads cookies across every site it can reach is a recognizable pattern anywhere. What an off-the-shelf tool can't do is resolve that "every site" against the specific hosts where a given org's SSO, secrets manager, and source control actually live, or know that the org's policy rules out a whole class of tool that's perfectly normal elsewhere. We'll dig into how the engine layers that context on top of the general evaluation, weighing capabilities in combination rather than in isolation and measuring access against an explicitly modeled set of the resources an org actually cares about, to land on an allow, block, or escalate-to-human decision. The system spans both sides: the analysis that produces a verdict and the action taken on it. A user asks for an extension through the Chrome Web Store's own request flow; the request is enriched, evaluated, and acted on automatically — Chrome policy applied, a review ticket opened for the hard cases, the right people notified. The same model of the environment that produces the verdict also shapes the guardrail: rather than a coarse approve-or-block, Chrome's policy schema lets an extension be allowed but fenced off from the specific hosts that environment flagged as sensitive, and the engine drives that control straight from the verdict. Automated security decisions tend to fail as black boxes: users route around controls they don't understand, and reviewers don't trust verdicts whose reasoning they can't see. So we treated the explanation as part of the control, not a log line. Alongside the decision, the engine assembles a plain-English justification from the facts that drove it, collapsing overlapping reasons into something that reads the way a human reviewer would write it. That justification surfaces in the portal: the interface where employees see what's approved, blocked, or under review, where a blocked extension becomes a self-service path to request a review rather than a dead-end, and where admins make and record the manual-review calls. The portal is where the whole system stops being a policy engine and becomes something people will actually use instead of work around. We run all of this in production today on static analysis: we reason about what an extension declares it can do, not what it does when it runs. We'll talk honestly about where that line holds, and where we're taking it next — dynamic analysis of runtime behavior. Attendees should leave able to reason about browser-extension risk in the context of their own environment, not a generic score built for someone else's.