Automating Browser Extension Security with LimaCharlie and Secure Annex

The browser is where the real work now happens, and the thing most security programs trust to watch it cannot actually see inside it. That is the tension John Tuckner, founder of Secure Annex, returns to throughout this conversation with Ken Westin, a solutions engineer at LimaCharlie. Endpoint detection and response tools treat a browser extension as just another thing on the endpoint, and teams assume the EDR understands what that extension is doing. Tuckner's whole argument is that it does not. An extension is a piece of software with broad permissions, installed without admin rights, sitting inside the application that touches your source code, your SaaS apps, and your sessions. Most security programs have spent years maturing application allow-listing and endpoint visibility, and then left this entire layer unmanaged.

A permission, not a file, is the real attack surface

The reason extensions slip through is structural. They do not need admin rights, so they bypass the controls that govern normal software. A user who cannot install a desktop VPN or a remote access tool can add the same capability as an extension in seconds. Tuckner is blunt about where this leads: he has talked to plenty of users who install a VPN extension specifically to get around their own IT controls, and a lot of those free VPNs are harvesting data on the side. The result is shadow IT through the browser, an entire class of capability arriving through a channel nobody is scoring.

What makes that dangerous is what the permissions allow once granted. Tuckner demonstrates this rather than asserting it. He flips on a test extension while browsing a GitHub repository, and in the background it quietly captures cookies, grabs screenshots of his activity, and watches for form data, with almost no interaction required from the user. Then he makes the point that matters most. He copies the stolen session cookies into a separate incognito window and loads the same repository as the impersonated user, with no login prompt at all. He even logs back in with a passkey first, the most advanced authentication most people have, and it changes nothing. Once the session cookie is captured, the strength of the authentication is irrelevant. The attacker is already that user, and not just on GitHub. The same technique applies to any SaaS app the person touches, from source control to Snowflake.

That is the conceptual shift Tuckner is pushing: stop thinking about extensions as files to be hashed and blocklisted, and start thinking about what their permissions let them do with the sessions and data already inside the browser.

Why trusting the marketplace is not a strategy

The obvious objection is that Google polices the Chrome Web Store, so surely the bad ones get caught. Tuckner uses the Cyberhaven compromise from the 2024 holiday period to dismantle that assumption. Cyberhaven is a legitimate, trusted security extension that, as Tuckner notes, did a genuinely good job protecting its users. Attackers compromised developer access and pushed a malicious version through the Web Store's auto-update mechanism, and that update reached not only Cyberhaven but roughly ten other organizations caught in the same campaign, affecting well over a million users. The malicious code carried the same cookie-capture-and-exfiltrate behavior Tuckner had just demonstrated. Westin connects this to a broader pattern he has watched develop: attackers shifting left, going after developers directly to reach source code and credentials, the same logic that shows up in North Korea's operations.

The uncomfortable part is the absence of good checkpoints. Either Google catches the bad update, or the organization diffs the extension version over version to spot what changed in obfuscated code, and neither of those is easy or fast. Trust, by itself, is the vulnerability. An extension you trusted without question becomes the source of compromise, and you find out afterward.

Closing the gap with enrichment and rules you can write

Secure Annex's answer is to make extensions legible at a scale no human review could match. It scans the extensions in the Chrome Web Store and builds a profile of each one that goes well beyond source code: the publisher, the stated purpose, the reviews, signatures, and known vulnerabilities. Then it uses AI to reconcile all of that into an assessment of what an extension is really doing, written so that an analyst who has never reviewed extension code can still understand the actual purpose and whether the extension is honoring it. Tuckner shows one that claims to be online antivirus but quietly rewrites the omnibox to redirect and harvest searches. Others monetize by selling clickstream data, which turns ugly the moment internal URLs, Jenkins instances, or sensitive headers get swept up and shipped to a third party. That is how an attacker performs reconnaissance against assets you thought were protected by conditional access, without ever touching them directly.

The integration is what makes this operational rather than informational. The ext-secureannex add-on in the LimaCharlie Marketplace pulls that structured enrichment into the endpoint agent, so it becomes telemetry you can write detection and response rules against like anything else. Tuckner walks through the kinds of rules that follow naturally: flag any extension classified as a remote access or proxy avoidance tool, since a desktop hash blocklist does nothing about the same capability arriving in the browser; treat extensions as part of vulnerability management and alert on critical vulnerabilities in their code; build suspicious-condition rules that combine signals like a stale manifest, a rating below three, fewer than a million users, broad permissions, or a high risk score. Because Secure Annex surfaces the URLs found inside an extension, that data can also be matched against an existing IOC feed.

For an MSSP or MDR, the value is less about any single detection than about owning a layer competitors are ignoring. Tuckner frames adoption as the same maturity progression security always follows: get visibility into which extensions and versions are installed, enrich that inventory to understand what each one does, then automate the response. The honest part is that the last step is still maturing. Asked whether he has built response actions to disable extensions across an organization, Tuckner says he has not yet, and that it is an open question how that gets executed through Google Workspace policies or endpoint registry changes. What exists today is fast, inspectable detection on a surface most teams never instrumented, which is what turns a Cyberhaven-style event from an after-the-fact discovery into something you can act on while it matters. Standing it up costs nothing to try: subscribe to the add-on, generate a Secure Annex API key, paste it into the extension, and the data flows automatically. LimaCharlie's free Community Edition, with its two sensors and two organizations, is enough to start.