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
permissionsarray along withwebRequest, it allowed the event listeners (likeonBeforeRequest) to be synchronous and return a blocking response object. - This response could tell the browser to
cancelthe request,redirectit 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.