webRequestBlocking

The webRequestBlocking permission was used in conjunction with webRequest in Manifest V2 to allow an extension to synchronously intercept, block, redirect, or modify network requests in-flight.

Note: In Manifest V3, this permission is restricted to extensions that are force-installed via enterprise policy (ExtensionInstallForcelist). Consumer extensions published on the Chrome Web Store cannot use it — Chrome rejects 'blocking' from extraInfoSpec when the extension was not policy-installed. The recommended replacement for blocking functionality in published extensions is the declarativeNetRequest API.

What it did

  • When added to the permissions array along with webRequest, it allowed the event listeners (like onBeforeRequest) to be synchronous and return a blocking response object.
  • This response could tell the browser to cancel the request, redirect it to a different URL, or modify request headers before they were sent.
  • It gave extensions the power to actively control and change network traffic in real-time.

When to use it

For extensions published on the Chrome Web Store, do not use this permission — use declarativeNetRequest instead. It is reserved for enterprise force-installed extensions that need synchronous network interception (e.g., bespoke corporate proxies, DLP tooling, internal SSO shims).

Examples (legitimate enterprise use):

  • A corporate DLP extension that needs to inspect outbound POST bodies in real time.
  • An enterprise proxy bridge that injects custom auth headers into managed traffic.
  • An internal-only ad/tracker blocker deployed via policy on managed devices.

Manifest Declaration

This MV3 manifest will only be functional when the extension is force-installed by enterprise policy. Loading it as a normal Web Store install will cause the 'blocking' extraInfoSpec to be silently dropped.

{
  "name": "My Enterprise Network Filter",
  "version": "1.0",
  "manifest_version": 3,
  "permissions": [
    "webRequest",
    "webRequestBlocking"
  ],
  "host_permissions": [
    "<all_urls>"
  ],
  "background": {
    "service_worker": "background.js"
  }
}

Security & Privacy

Why is it risky?

This permission, combined with webRequest, created one of the most powerful and dangerous capabilities an extension could have. Not only could it see all of your internet traffic, it could also actively block, change, or redirect it.

A malicious extension could use this to:

  • Redirect you to phishing websites that look like your bank to steal your password.
  • Block your access to security software updates or legitimate websites.
  • Inject malware or tracking scripts into otherwise safe websites.

Because this permission is so powerful and privacy-invasive, in Manifest V3 it is restricted to extensions force-installed by enterprise policy; consumer extensions on the Chrome Web Store must use the much safer and more private declarativeNetRequest API, which prevents the extension from reading your network activity.

API Usage Example

This example blocks all requests to analytics.example.com synchronously. The third argument ["blocking"] is what makes the listener able to return { cancel: true }.

// background.js (service worker; only takes effect when policy-installed)

chrome.webRequest.onBeforeRequest.addListener(
  (details) => {
    console.log("Blocking request:", details.url);
    return { cancel: true };
  },
  { urls: ["*://analytics.example.com/*"] },
  ["blocking"] // Requires `webRequestBlocking` AND a policy-installed extension in MV3
);

Extensions with the webRequestBlocking permission

Here are some popular browser extensions that use the "webRequestBlocking" permission. To explore more, try our Advanced search.

Permission Metrics

Popularity

Security Risk


Usage by Platform