Extenshiextenshi.io/blog
Back to articles
privacybrowser-extensionspermissionsdebuggerchrome-extensionsdevtools-protocol

The `debugger` permission explained: what browser extensions can really do with DevTools access

The debugger permission gives an extension full Chrome DevTools Protocol access — cookies, keystrokes, any page. Here's what it allows and how to check yours.

Maxim Kosterin
9 min read

The most powerful permission a Chrome extension can hold has the most boring warning text in the whole list. One word in the manifest — debugger — and Chrome tells you: "Access the page debugger backend."

That sounds like developer plumbing. It isn't. The debugger permission lets an extension drive your browser the same way an automated test harness drives a throwaway one — except it's your browser, with your logins, your sessions, and your open tabs.

I've written up the loud permissions before: <all_urls>, cookies, nativeMessaging. debugger is the one that quietly contains most of them.

What the debugger permission actually is

Declaring "debugger" in the manifest unlocks the chrome.debugger API. That API is a bridge to the Chrome DevTools Protocol — CDP, the same low-level wire protocol DevTools itself speaks, and the one Puppeteer and Playwright use to automate Chrome.

Normally an extension talks to a page through a content script. That script runs in an isolated world: it sees the DOM, but not the page's own JavaScript variables, and it plays by the page's Content Security Policy. CDP has no such fence. It's the layer underneath.

The mental model I use: a content script is a guest in the room. A debugger attachment is the room's blueprint, the light switches, and the keyboard.

What it actually allows

Chrome exposes a subset of CDP domains to extensions — not the full protocol, which is a deliberate security decision. The subset is still enormous. Among the domains available: Network, Input, Page, Runtime, Storage, DOM, Fetch, and WebAuthn.

Translated out of protocol-speak, an extension attached to a tab can:

  • Read and write any cookie in the browser, including HttpOnly cookies that JavaScript on the page can never touch. Session tokens live there.
  • Synthesize input. Input.dispatchKeyEvent and Input.dispatchMouseEvent produce clicks and keystrokes the page cannot distinguish from yours.
  • Run arbitrary JavaScript in the page's main world, with the page's own variables in scope — no isolation, no CSP in the way.
  • Watch every request and response, headers and bodies included, and rewrite them in flight.
  • Read the page's storage — localStorage, IndexedDB, service worker caches.

Notice how much of that overlaps with permissions Chrome does warn loudly about. cookies gets its own scary line at install. So do webRequest and scripting.

The debugger permission folds all of that into one dry sentence about a backend. And it applies to whatever tab the extension attaches to — not to a declared host pattern you can read off the listing.

One more wrinkle worth knowing. Manifest V3 bans remotely hosted code, but Chrome's Web Store program policies treat the Debugger API as one of the documented, allowed routes for executing logic from a remote source. An extension with debugger sits inside that carve-out.

The banner is most of the security model

Here's the good news, and it's real: Chrome does not let this happen silently. The moment an extension attaches, Chrome pins a yellow infobar to the top of the browser — "[Extension name] started debugging this browser."

You've probably seen it. Accessibility testing tools, RPA and workflow automation extensions, and AI browser agents all trigger it. Anthropic's Claude in Chrome extension produces it on every tab. That generated a long feature request on the Claude Code tracker asking for a way to turn it off.

OpenAI's Codex extension asks for the same permission — I went through its permission stack in my AI agent permissions breakdown.

That banner is a genuinely good design. It's also thinner than it looks:

  • You can dismiss it. Clicking Cancel closes the bar; the extension keeps its attachment.
  • Chromium ships a command-line switch, --silent-debugger-extension-api, that suppresses the warning entirely.
  • Extensions installed by enterprise policy through ExtensionInstallForcelist don't raise it in the first place — which is exactly the install path a compromised corporate deployment would use.

So the model is: loud by default, quiet if anyone with local access wants it quiet.

What researchers found when they went looking

The most thorough public work on this is a paper from IMDEA Networks and UC3M, "Chrowned by an Extension: Abusing the Chrome DevTools Protocol through the Debugger API", presented at IEEE EuroS&P 2023.

Their core finding is an isolation problem. CDP was built for debugging a browser instance, not for being handed to a semi-trusted extension. So some commands are scoped to the whole browser rather than to the tab being debugged.

The authors report that Network.getAllCookies returns cookies across the browser instance, not just the attached target. They also report that incognito targets could be listed and attached to without the extension holding incognito access.

The findings were disclosed to Google. I haven't been able to confirm which individual issues were closed, or when, so treat the specifics as a 2023 snapshot. The architectural point is what carries forward — and it keeps resurfacing.

Two entries in Chrome's own bug tracker make that concrete. One from January 2026 describes the chrome.debugger API not validating extension ownership when attaching to a target. An extension holding debugger plus access to chrome-extension:// URLs could then attach to another extension's background page or service worker and run code inside it. Password managers included.

An older entry covers reading local file contents through the same API. I can't verify the current fix status of either from the outside, so I'm citing them as documented reports, not as live holes.

On the malware side, Palo Alto Networks Unit 42 reported in April 2026 on 18 malicious or high-risk AI extensions. One of them, marketed as an MCP browser-control tool, allegedly ran a WebSocket command channel with HTTPS interception via the Chrome Debugger Protocol — one of its 30-plus supported commands. Unit 42 says it notified Google, and that the extensions were removed or issued policy warnings. I haven't found independent corroboration of that report from a second research team, so read it as one vendor's findings rather than settled fact.

When it's fine, and when to look twice

Usually fine:

  • Browser automation, RPA, and end-to-end testing extensions. Driving the browser is the product.
  • Accessibility auditing tools that need the Accessibility and DOM domains.
  • Performance profilers and network inspectors — CDP is the only way to get that data.
  • AI browser agents that act on your behalf, provided you knew that's what you installed and the banner shows up.

Worth a second look:

  • Any extension whose stated job doesn't obviously require driving a browser. A coupon finder, a theme, a note clipper, a PDF tool — none of these need CDP.
  • debugger paired with broad host access on a listing from a developer you can't identify.
  • An extension that changed hands recently. Ownership transfer inherits the install base and the already-granted permission, and debugger is the single most valuable one to inherit.
  • An extension you were told to install by "IT support" over chat. Force-installed and sideloaded extensions skip the banner.

The rule I'd apply: debugger is not a permission to be alarmed by, it's a permission to be deliberate about. A handful of legitimate categories genuinely need it. Everything outside those categories asking for it is a question worth answering before you click Add.

How to check your extensions

The manual pass takes a minute:

  1. Open chrome://extensions/.
  2. Click Details on an extension.
  3. Read the Permissions section. If debugger is declared, you'll see the "page debugger backend" line — Chrome's permissions reference lists the exact warning each permission triggers.
  4. If you ever see the debugging banner and can't name the extension that caused it, that's your signal to go looking.

Firefox users get a shortcut here: there is no equivalent. The request to implement chrome.debugger for WebExtensions has sat open in Bugzilla since 2016, and Firefox exposes its remote debugging protocol through developer tooling rather than through an add-on permission. One fewer capability for add-ons, one fewer thing to audit.

Doing step 2 across 15 installed extensions gets old fast, and the permission you most want to catch is the one buried in the most boring wording. The Extenshi catalog lists every declared permission per listing. So you can see which of your extensions hold debugger, and what else they hold alongside it, without opening 15 Details pages.

Check your permissions →

Permissions aren't dangerous in proportion to how frightening they sound. debugger proves it: the flattest sentence in the install dialog describes the deepest access in the browser.

Why does it say "[Extension name] started debugging this browser"?

That yellow bar is Chrome telling you an extension has attached the debugger permission to a tab. It's not an error, and on its own it's not a sign of compromise — automation and AI-agent extensions trigger it by design. Tricentis, UiPath, Power Automate, Claude in Chrome and Codex all produce it.

It does mean that for as long as the bar is up, the extension it names can read and write anything in that tab, cookies included.

You can't hide it, and that's deliberate. If you don't recognize the extension named, that's the signal to act on.

Sources

This article is based on publicly available security research, official browser documentation, and public issue trackers. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].

Related Articles