Extenshiextenshi.io/blog
Back to articles
privacybrowser-extensionspermissionsclipboardchrome-extensionsclipboardread

The `clipboardRead` permission explained: what an extension sees when you copy and paste

The clipboardRead permission lets an extension read your clipboard with no prompt and no click. Here's what it allows — and the trick that needs no permission.

Maxim Kosterin
9 min read
A line-drawn clipboard holding a sheet with one line painted in orange watercolour, a dashed path carrying a copy of that line off the board into empty space
A line-drawn clipboard holding a sheet with one line painted in orange watercolour, a dashed path carrying a copy of that line off the board into empty space

Think about what has passed through your clipboard in the last hour. A password you pulled out of your manager. A 2FA code. Maybe an API key, a wallet address, a chunk of a private document you were moving between tabs.

The clipboard is the one place on your machine where sensitive strings sit in plaintext, unencrypted, by design. And Chrome has a six-word install warning for clipboardRead, the permission that reads it: "Read data you copy and paste."

That one is actually pretty honest, as these strings go. The problem is what sits next to it — a second path to your clipboard that carries no warning at all.

What the clipboardRead and clipboardWrite permissions actually mean

There are two of them, and they split along the obvious line.

clipboardRead maps to the warning "Read data you copy and paste." Per Chrome's permissions list, it lets an extension paste items from the clipboard using the web platform Clipboard API.

clipboardWrite maps to "Modify data you copy and paste" — cut and copy to the clipboard.

The line in Chrome's docs that matters most, and that almost nobody quotes: with clipboardRead, an extension can read the clipboard without user confirmation or transient activation.

On a normal web page, navigator.clipboard.readText() is gated. The browser wants a permission prompt or a real user gesture before a site sees what you copied. clipboardRead removes both gates. The extension asks, and the string arrives.

What it actually allows

An extension holding clipboardRead can call navigator.clipboard.readText() on demand and get whatever is sitting on your system clipboard right now. Not "clipboard data from this page." The system clipboard — including the thing you copied out of your password manager, your terminal, or a different application entirely.

What it can't do is get notified. There's no onClipboardChanged event in the extension APIs. To watch your clipboard continuously, an extension has to poll it or hook something that fires — which is why persistent clipboard monitoring needs a page or a document staying alive to do the asking.

That constraint got more visible under Manifest V3. Service workers have no DOM, and neither document.execCommand() nor navigator.clipboard is exposed to workers, so an MV3 extension can't touch the clipboard from its background script at all.

The documented route is an offscreen document created with the reason CLIPBOARD — an invisible page whose only job is to hold a DOM so the clipboard call works. Google ships a runnable sample of exactly this. I walked through the general mechanism in the offscreen documents piece.

So in a modern manifest, the honest shape of "this extension reads your clipboard in the background" is clipboardRead + offscreen together.

The path that needs no permission at all

Now the part that changes how I read these manifests.

The W3C Clipboard API and events spec defines copy, cut and paste as ordinary DOM events carrying a clipboardData object. As MDN puts it, a handler for the paste event can read clipboard contents by calling getData() on that object — and those event-based APIs work inside a ClipboardEvent handler without the permission dance.

A content script is JavaScript running in your page. It can register those handlers.

Which means an extension with host permissions on a site — and no clipboard permission whatsoever — can read anything you paste into that page, and rewrite anything you copy out of it. The rewrite is the classic pastejacking move: listen for copy, call clipboardData.setData() with different text, call preventDefault() so nothing else gets written. You copied one thing. Your clipboard holds another.

The scope limit is real and worth stating plainly: this path only sees copies and pastes that happen on pages the content script runs on. It is not your whole clipboard history. clipboardRead is the broader capability. But "broader" isn't the same as "the only one," and <all_urls> host access narrows that gap considerably — every page becomes a page the script runs on.

The upshot for anyone auditing a manifest: the absence of a clipboard permission does not mean an extension can't touch your clipboard.

Real examples

The clipper family is where this stops being theoretical.

In June 2026, McAfee Labs researchers described a campaign they call Silent Swap — a fake "Google Notes" extension that, according to their analysis, monitors copy-paste activity, recognizes cryptocurrency wallet addresses across several blockchains, and substitutes an attacker-controlled address before the victim pastes. The behavior was corroborated in secondary reporting by The Hacker News.

One detail from that write-up deserves its own sentence: the researchers report the extension didn't arrive through the Chrome Web Store at all. An unsigned installer edited Chromium's own configuration files to force-install it. Store review never entered the picture — which is a reminder that "I only install from the Web Store" is a partial defense, not a complete one.

On the Firefox side, Socket's research into a campaign spanning 77 add-on identities found that several of the extensions collected credentials and clipboard contents through a hardcoded command-and-control server, alongside wallet secrets. Socket notes Mozilla removed the flagged add-ons after being notified. Neither McAfee nor Socket has had their findings independently re-tested by a second research team as far as I can tell, so read them as one team's analysis each.

Plenty of legitimate tools want this too, and their stories hold up: password managers, clipboard history managers, snippet and template tools, markdown converters that turn a copied table into text, anything with a "copy as…" button.

When it should give you second thoughts

Same test I apply to every permission — does the extension's visible job require it?

A clipboard manager declaring clipboardRead is the product. A password manager needs clipboardWrite to put a credential where you can use it. Fine, both.

Three mismatches I'd flag hardest:

  • clipboardRead without a visible clipboard feature. If nothing in the UI shows you your clipboard or acts on it, reading it isn't serving you. clipboardWrite alone is much less interesting — writing is the half that doesn't exfiltrate.
  • clipboardRead paired with offscreen in something that isn't a clipboard tool. That combination is the documented recipe for background clipboard access. It has honest uses, but it deserves a reason.
  • Broad host permissions on a tool that has no business reading your pages. That's the no-permission path above, and it will never show up as a clipboard warning.

Standing caveat, as always: a declared permission is capability, not behavior. Most extensions asking for this are doing the boring legitimate thing. Across the 308,000 listings I pulled permission data from, the genuinely over-reaching slice stays small enough to actually scrutinize.

Is there a clipboard read permission in Firefox?

Yes, with its own quirks. Per MDN, Firefox has supported clipboardRead since Firefox 54, but pasting only works into content-editable elements — which in a content script means a <textarea>. The event-based copy / paste path from above is web-platform behavior, so it works the same way in both browsers. Don't assume parity on the permission, and don't assume the absence of a warning means the absence of the capability.

How to check your own extensions

  1. Open chrome://extensions, click Details on each one, and read the permission lines. "Read data you copy and paste" is clipboardRead; "Modify data you copy and paste" is clipboardWrite.
  2. For anything showing the read warning, ask what feature consumes it. If you can't point at one in the UI, that's your answer.
  3. Check the host permissions on the same screen. "Read and change your data on all websites" means the no-permission clipboard path is available to it too, whatever the clipboard warnings say.
  4. If you move crypto: paste wallet addresses into a plain text field and verify the first and last characters before you send. The whole clipper business model depends on you not looking.

Doing this by hand, one warning at a time, for thirty installed extensions is the job everyone abandons around number six. Cross-referencing what each extension declares against what it plausibly needs is what the Extenshi catalog does for you.

Check your permissions →

The clipboard is a weird blind spot. We've trained ourselves to be suspicious of anything that reads our browsing history, and meanwhile the string that just moved between our password manager and a login form gets no scrutiny at all. It should get some.

FAQ

What does "Read data you copy and paste" mean on a Chrome extension?

It's the install warning for the clipboardRead permission. The extension can read your system clipboard through the Clipboard API — and per Chrome's documentation, it can do so without user confirmation or transient activation, which is the gating a normal web page has to pass.

Can an extension read my clipboard without the clipboard permission?

Partly, yes. Clipboard events (copy, cut, paste) expose their data to handlers without requiring the permission, so a content script on a page can read what you paste there and alter what you copy from it. It doesn't get your full clipboard on demand the way clipboardRead does, but the gap narrows as host permissions widen.

Why does an MV3 extension need an offscreen document for the clipboard?

Service workers have no DOM, and neither document.execCommand() nor navigator.clipboard is available to them. Chrome's documented workaround is an offscreen document created with the CLIPBOARD reason — an invisible page that provides the DOM the clipboard call needs.

Sources

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].

Related Articles