Host permissions explained: what 'read and change all your data on all websites' really means

There's a Chrome dialog that most people click past without reading.

You find an extension you want, hit "Add to Chrome," and a permissions popup appears:

"This extension can: Read and change all your data on all websites you visit."

Then you click "Add extension" anyway. I do it too sometimes — and I build tools for extension security. But that warning isn't theater. It describes one of the most powerful things an extension can do, and most users have no idea what it actually covers.

Here's the technical truth behind that one sentence.

What host permissions are

Every browser extension declares its capabilities in a manifest.json file. Host permissions live in the host_permissions array (or in the permissions array for older Manifest V2 extensions):

{
  "host_permissions": ["<all_urls>"]
}

<all_urls> is the broadest possible pattern. It matches every URL — http://, https://, ftp://, and file://. That's your bank, your email, your health records portal, your work tools.

Some extensions are more targeted:

{
  "host_permissions": ["https://mail.google.com/*"]
}

That version only covers Gmail. Still significant, but scoped to one service. Chrome generates the scary "all websites" warning specifically when the declared patterns are broad enough to cover most of your browsing.

What it actually allows

This is where it gets real. Host permissions aren't just a flag — they unlock several capabilities that run completely in the background.

Content script injection. Extensions with host permissions can inject JavaScript directly into the pages you visit. That script runs inside the page — it can read the DOM, capture form inputs (including passwords before they're submitted), scrape any data the page renders, and observe user interactions. You won't see it happening.

Network request observation. Extensions can monitor network activity for any host they have permission over. They can see what requests your browser is making and what responses come back. In Manifest V2, extensions could also modify or block those requests outright via webRequest; in MV3 that's restricted, but observation remains possible.

Cookie access. Combine host permissions with the cookies permission and an extension can read, write, and delete cookies for any site it covers — including session tokens that keep you logged in. I broke down exactly how that works in my earlier piece on the cookies permission.

Tab awareness. Extensions with host permissions can use the tabs API to observe URLs and page titles across your browsing session, tracking which sites you visit and when.

None of this is hidden. It's all documented on MDN and in Chrome's developer documentation. The problem isn't that it's secret — it's that the gap between "documented" and "visible to users" is exactly where privacy risks accumulate.

Who legitimately needs this

Ad blockers are the obvious case. uBlock Origin, AdGuard, and every other content filter needs <all_urls> because ads appear on every site. An ad blocker that only works on specific domains you pre-approve isn't useful.

Password managers are the same story. Bitwarden, 1Password, and their competitors need to detect login forms on any website you visit. That requires broad host access by design.

Shopping assistants, reading mode tools, and developer debugging extensions (like React DevTools) have similar justifications — they need to run on arbitrary pages to do their jobs.

The permission itself is neutral. What matters is what the extension does with access once it has it.

When it becomes a problem

Security researchers documented a 2026 campaign where more than 300 Chrome extensions, collectively installed by tens of millions of users, abused <all_urls> host permissions to silently exfiltrate browsing data, email content, and session information. The extensions appeared functional and had passing review scores. They requested the exact same permissions as a legitimate ad blocker.

According to Keep Aware's 2026 State of Browser Security Report, 13% of enterprise browser extensions they analyzed as of early 2026 were rated high or critical risk. Broad host permissions were a common factor in that category.

Some specific patterns should raise your suspicion:

Disproportionate permissions. A color picker that requests <all_urls> has no obvious need to read your banking portal. A tab organizer doesn't need to observe your email. When the declared capability far exceeds what the extension's feature set requires, that mismatch is worth investigating.

New extension with no history. A freshly published extension with minimal reviews requesting <all_urls> is a higher-risk profile. The extension acquisition market — where attackers buy established, trusted extensions to push malware updates — makes even older extensions worth re-checking periodically.

<all_urls> paired with cookies and storage. This combination gives an extension everything it needs to maintain persistent access to your sessions across sites. Legitimate tools sometimes need it; malicious ones always want it.

Manifest V3 and where things are heading

MV3 introduced optional host permissions, which lets users grant access on a per-site basis rather than globally at install time. In theory, you install an extension and it only gets broad access after you approve it for specific domains.

In practice, most extensions still request <all_urls> upfront and rely on users clicking through. Adoption of the optional permissions model is slow.

One concrete tightening happened in Chrome 146: Google introduced a Selective Permission Intervention that blocks advertising-related JavaScript running on web pages from accessing privacy-sensitive device APIs — geolocation, microphone, clipboard, Bluetooth, USB, and display capture. According to the Chrome Enterprise release notes, this applies to third-party ad scripts in page contexts, not to extension code itself. Extensions still retain the same host permission capabilities.

But the direction is clear. Google is compartmentalizing access more aggressively, and it's worth understanding what the current model still allows before those restrictions arrive.

How to check your own extensions

You don't need to audit source code. A few straightforward steps will give you a clear picture:

1. Open chrome://extensions and click "Details" on each installed extension. Look for the "Site access" section — it shows whether the extension has access to all sites, specific sites, or only when you click it.

2. Restrict access where possible. On the details page, Chrome lets you change "On all sites" to "On specific sites" or "Only when you click the extension" for many extensions. Ad blockers won't work this way, but plenty of other tools can be safely restricted without breaking functionality.

3. Search the Extenshi catalog for any extension you're unsure about. The scan shows declared permissions alongside the extension's category, so you can judge whether the permission set matches what the extension actually does.

4. Remove extensions you haven't used recently. An unused extension still has full active permissions. Deleting it eliminates the attack surface entirely.

Host permissions are powerful by design — the browser couldn't function well as a platform without them. But "read and change all your data on all websites" is a genuine capability, not marketing language. Understanding what's behind it is the starting point for making informed decisions about what you install.

Check your permissions now →

This article is based on publicly available security research and news reporting. 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].