Extenshiextenshi.io/blog
Back to articles
privacybrowser-extensionspermissionsstoragechrome-extensionsdata-story

The `storage` permission explained: what browser extensions keep, and where it actually lives

The storage permission is the most-requested thing extensions ask for — 62% claim it, with no install warning. Here's what it keeps, where, and how to check.

Maxim Kosterin
7 min read
A quiet stack of thin hairline layers with one middle layer in soft orange watercolor — data an extension keeps, silently, at rest.
A quiet stack of thin hairline layers with one middle layer in soft orange watercolor — data an extension keeps, silently, at rest.

I pulled the declared permissions for every live listing in the Extenshi catalog a few weeks back — 308,210 extensions across Chrome, Firefox, and Edge. One entry beat everything else, and it wasn't close. storage shows up in 191,369 of them: 62.1% of the whole ecosystem.

So the most common thing an extension asks for is permission to keep data. And here's the part most people never notice: when you install an extension that requests storage, Chrome shows you no warning at all. No "this extension can…" line. Nothing. It's one of the quietest permissions there is, sitting on top of the biggest pile of extensions.

That combination — most requested, completely silent — is exactly why it's worth understanding. Not because storage is scary. Because it teaches you how to read the rest of the list.

All figures below come from the Extenshi catalog snapshot taken on 2026-06-01. These are declared manifest permissions, not scanner verdicts — asking for something isn't proof of doing anything bad with it.

What the storage permission actually is

Declaring "storage" in the manifest unlocks the chrome.storage API. That's it. It's a place for the extension to save data that survives across page loads, browser restarts, and — importantly — sometimes across your other devices.

Think of it as the extension's own little database. Your dark-mode toggle, your saved filters, a cached copy of your settings, the list of sites you told it to ignore — all of that lives in chrome.storage. Almost every genuinely useful extension needs somewhere to keep state, which is why the number is 62% and not 6%.

By itself, storage doesn't let an extension read your browsing, touch a web page, or see your cookies. Those are different permissions with their own taps. storage is the bucket, not the hose. The privacy question isn't "can it store data" — it's where that bucket lives, and what other permissions are pouring into it.

What it actually allows — the four storage areas

chrome.storage isn't one thing. It splits into areas — the same set Firefox and Edge expose through the cross-browser WebExtensions storage API — and the differences matter for privacy:

  • storage.local — data saved on your disk, on this device only. Cleared when you remove the extension. Around 10 MB by default (5 MB on Chrome 113 and earlier), and an extension can lift that cap entirely with the separate unlimitedStorage permission.
  • storage.sync — this is the one to sit up for. If you have Chrome sync on, whatever an extension writes here syncs to every Chrome browser you're signed into, routed through Google's servers. It's capped small — about 100 KB total, 8 KB per item — but the point is that the data leaves your machine.
  • storage.session — kept in memory, wiped when you close the browser. Chrome recommends this one for anything sensitive, precisely because it doesn't hit the disk.
  • storage.managed — read-only, set by an enterprise admin via policy. Your workplace, not the extension, controls it.

Here's the fact that surprises people: storage.local and storage.sync are not encrypted. Chrome's own documentation says outright not to store confidential data there. Whatever an extension saves sits in plain text inside your browser profile folder, readable by anything on your machine that can reach those files.

Why "unencrypted and on disk" is the real privacy angle

On its own, that's fine — most extensions store boring settings. The problem shows up when storage teams up with permissions that do collect sensitive things.

An extension that also holds broad host access or the cookies permission can read real data off the pages you visit — and chrome.storage is a natural place to park it before sending it anywhere.

When you read about infostealer malware "harvesting browser extension data," this plaintext-on-disk layer is part of what they're scraping — and security teams tracking extension risk, like Spin.AI in its browser-extension risk report, keep flagging how much sensitive data extensions quietly accumulate. storage is the warehouse; the dangerous permissions are the delivery trucks backing into it.

And storage.sync adds a second wrinkle: data an extension writes there doesn't just sit locally, it gets copied to your other signed-in browsers through your Google account. For a settings blob, that's a convenience. For anything an extension has quietly scooped up, it's a quiet off-device hop most users never picture happening.

When it's fine and when to look twice

Almost always fine:

  • The extension's whole job needs saved state — a to-do list, a tab manager, a theme switcher, an ad blocker keeping its filter rules.
  • storage is the only eyebrow-raising permission on the list. A bucket with nothing feeding it is just a bucket.

Worth a second look:

  • storage paired with <all_urls>, cookies, scripting, or webRequest on a tool whose stated purpose doesn't explain why it needs to read your pages. The storage isn't the tell — the combination is.
  • An extension that changed hands recently. Ownership-transfer attacks inherit an established extension's install base and its already-granted permissions, then start using them differently.
  • A privacy policy that never mentions what data is kept or where it goes, on an extension that clearly holds data-collecting permissions.

The mental model I keep coming back to: don't rank permissions by how scary the word sounds. storage sounds harmless and mostly is. Rank them by what flows into the store.

I mapped the full ecosystem in my permission-footprint breakdown — the entries actually worth pausing on (<all_urls> at 7.4%, cookies at 5.1%) are the ones with real reach, and they're far rarer than storage.

How to check what your extensions keep

Chrome won't surface storage in the permissions dialog — remember, it's silent — so the manual route only gets you partway:

  1. Open chrome://extensions/.
  2. Click Details on an extension.
  3. Read the Permissions and Site access sections. You won't see "storage" listed, but you will see the loud ones — "Read and modify your data on all websites you visit" — which are the permissions that make an extension's storage worth worrying about.

That's the catch: the permission you can't see is only a concern because of the ones you can. Checking each extension by hand across a dozen installs gets old fast. The Extenshi catalog lists every declared permission an extension holds — including storage and everything feeding it — so you can see the full combination at a glance instead of guessing which quiet permissions pair with the loud ones.

The check worth running today: for any extension that holds broad site access and storage, ask whether its actual job explains that pairing. If it doesn't, that's your signal to dig into who makes it and what its privacy policy admits to.

Check your permissions →

storage is the most-requested permission in the entire extension world, and it's the one Chrome never warns you about. That's not a scandal — it's a lesson in reading the list properly. The quiet entries hold your data; the loud ones decide what ends up in there.

Sources

This article is based on publicly available security research, official Chrome documentation, and first-party data from the Extenshi catalog. 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