The `webRequest` permission explained: what browser extensions can really see in your traffic

Most permissions reach into one thing. cookies touches your cookies. tabs sees your open tabs.

The webRequest permission is different — it sits on the wire. When an extension holds it, every request your browser makes passes under its nose: the URL, the headers, sometimes the body, and the response coming back.

That includes the boring stuff (loading a CSS file) and the sensitive stuff (the API call that carries your auth token, the analytics beacon, the login POST). So it's worth understanding what this permission actually grants before you wave one through at install time.

In the Extenshi catalog snapshot from 2026-06-01, webRequest shows up in 16,433 of 308,210 live listings — about 5.3%. Its blocking variant, webRequestBlocking, appears in 6,499 (2.1%). Not the most common permission by a long way, but the ones that have it are the ones watching your network.

What webRequest actually allows

The webRequest API lets an extension register listeners that fire at each stage of a network request's lifecycle — before the request is sent, when headers are about to go out, when the response headers come back, and so on. At each stage the extension gets handed details about the request.

What's in those details depends on the matching host permissions, and that's the part people miss. webRequest on its own is mostly inert. Paired with a broad host pattern like <all_urls>, it becomes a tap on everything.

At that point the extension can read the full URL of every request, the request and response headers, the method, and the resource type. Headers are the spicy part — that's where session cookies, Authorization bearer tokens, and CSRF tokens travel.

So the honest mental model is: webRequest is the capability, and host permissions decide how much of your traffic it applies to. An extension scoped to *://*.example.com/* only sees example.com requests. One scoped to <all_urls> sees the lot. I broke down what that broad scope means in my earlier piece on host permissions.

Observe versus modify

There are two flavors of this permission, and the difference matters.

Plain webRequest is read-only. The extension watches requests and can collect details, but it can't change or block them. Think of it as a wiretap that can't cut the line.

webRequestBlocking adds the power to act — cancel a request, redirect it somewhere else, or rewrite headers before they're sent. That's how old-school ad blockers killed tracker requests, and it's also, in the wrong hands, how an extension could strip a security header or quietly reroute a request to an attacker's server.

Under Manifest V3, Google deliberately cut back the blocking flavor. The blocking webRequest API is largely restricted to force-installed enterprise extensions now, and Google's migration guidance pushes everyone else toward declarativeNetRequest — a system where the extension hands Chrome a list of rules and never sees the request content itself.

That trade-off sparked years of argument about ad blocking; I dug into the actual effectiveness data in my post on the MV3 ad-blocking study. The privacy upside is real, though: declarative rules can't read your headers, so a tracker-blocker built on them literally cannot exfiltrate the traffic it's filtering.

Real examples: who legitimately needs it

Plenty of useful extensions ask for webRequest, and for good reasons.

Ad blockers and privacy filters are the classic case — they need to see requests to decide which trackers to drop. Under MV2 that meant webRequestBlocking; under MV3, tools like uBlock Origin Lite moved to declarativeNetRequest, while some holdouts still lean on the observational webRequest for logging and diagnostics.

Developer tools are another. Anything that shows you a network waterfall, captures HAR files, or debugs API calls genuinely needs to observe requests. Enterprise security agents use it too, to log or block traffic for compliance. None of that is a red flag on its own.

The point isn't "extensions with webRequest are bad." It's that a permission this powerful should match the extension's job. A network-debugging tool wanting it makes sense. A cursor-theme extension wanting it does not.

When it's fine, and when to pause

Here's how I think about it before installing.

Fine: the extension's whole purpose is networking — blocking, filtering, debugging, VPN-style routing — and its host permissions are scoped to where it needs to work. A coupon tool that only activates on shopping sites asking for request access to those sites is a coherent ask.

Worth pausing: the extension requests webRequest plus <all_urls> but its described features have nothing to do with traffic. A note-taking tool, a theme, a screenshot helper — none of those need to watch every request you make. When the permission outruns the feature set, that gap is the signal. It doesn't prove anything malicious; it means the extension could see far more than its stated job requires, and you're trusting it not to.

Also worth a second look: extensions that combine webRequest with cookies. On its own each is explainable, but together they describe an extension positioned to read both your requests and the session tokens those requests carry. I covered the cookie side in my post on the cookies permission.

How to check your extensions

You can see this yourself in a couple of minutes.

Open chrome://extensions, flip on Developer Mode in the top-right, and click "Details" on any extension. The permissions section lists what it declared. webRequest and webRequestBlocking show up by name; the "read and change all your data on all websites" line tells you the host scope it's paired with.

If you want to know which of your installed extensions hold network permissions — and how they score on privacy and security rather than just what they declared — scan your extensions on Extenshi. Declared permissions tell you what an extension can do; the scan is where you start separating the routine from the ones worth uninstalling.

The webRequest permission is a normal, legitimate tool. It's just one of the few that sees your traffic instead of one corner of your browser — so it earns a closer look than the dialog gives it.

Check which of your extensions can read your network traffic →

---

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