Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 129353 chrome.webRequest.onBeforeRequest doesn't intercept WebSocket requests
Starred by 103 users Reported by, May 23 2012 Back to list
Status: Fixed
Closed: Mar 3
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on: View detail
issue 116624
issue 226931

Sign in to add a comment
Chrome Version       : 21.0.1148.0

What steps will reproduce the problem?
1. Create an extension with "webRequest" and "*://*/*" host permissions.
2. Add listener to "chrome.webRequest.onBeforeRequest" in extension's code.
3. Open new tab and perform a WebSocket request to any URL.

What is the expected result?
Listener intercepts request.

What happens instead?
Request is sent without interception.

Please provide any additional information below. Attach a screenshot if
Also, it seems that "ws://" and "wss://" schemes per se are not supported in "permissions" property in application manifest, same as in "urls" property in RequestFilter object. The extension described above intercepts other (non-WebSocket) types of requests as expected.
Comment 1 by, May 24 2012
Labels: Feature-Extensions WebKit-WebSockets
+battre, mpcomplete

I'm not sure that webRequest API should support WebSocket.
But, it's clear that WebSocket doesn't work with webRequest API for now.

How about other protocol supports? This API looks HTTP(S) specific to me.
Comment 3 by, May 24 2012
Status: Available
I am not very familiar with WebSockets but from a quick look at wikipedia it seems to me like we should provide the WebRequest API to observe and influence the handshake.

My impression is that the WebSockets implementation does not have much code in common with the URLRequest implementation. We would basically mimic the calls to the network delegate from URLRequest, URLRequestJob and maybe URLRequestHttpJob (see the occurrences of context()->network_delegate()
Blockedon: 116624
Yes, currently WebSocket doesn't share codes with chromium http stack because WebSocket protocol is implemented in WebKit for a historical reason (We should share the protocol stack implementation with other WebKit ports).

I think it's a little tough work to provide mimic delegates for now.

On the other hands, WebSocket implementation will be moved into chromium network stack because we should implement multiplexing not in renderer process, but in browser process. After this refactoring, providing mimic delegates will become easy task because it will share http stack for handshakes.

Can we wait for this refactoring to provide WebSocket support in webRequest?
Comment 5 by, May 25 2012
Yes, I think it makes sense to do this after the refactoring.
Labels: -Pri-2 -Area-Undefined Pri-3 Area-Internals
Comment 7 by, Jun 13 2012 may be relevant to this.
+bashi is originally a change to support "URLBlacklist" group policy feature (
I'm not sure that the mechanisms used in both of the policy feature and webRequest are the same one.
Comment 9 by, Jun 14 2012
Looks like the implementation of webRequest APIs is bounded tightly with URLRequest, unlike URLBlacklist. I think it'd be better to support this after refactoring.
The usual support for policy based URL blacklists is in ChromeNetworkDelegate::OnBeforeURLRequest, which is shared to be used by the WebRequest API and the policy based URL blacklists.

My point was that once we support the webRequest API for web sockets, we should also have a shared place to do policy based blacklisting and webRequest API based cancelling.
Comment 11 by, Aug 12 2012
Blockedon: -chromium:116624 chromium:116624
Project Member Comment 12 by, Mar 10 2013
Labels: -Area-Internals -Feature-Extensions -WebKit-WebSockets Cr-Platform-Extensions Cr-Content-WebSockets Cr-Internals
Project Member Comment 13 by, Apr 6 2013
Labels: Cr-Blink
Project Member Comment 14 by, Apr 6 2013
Labels: -Cr-Content-WebSockets Cr-Blink-WebSockets
Comment 15 by, Aug 14 2013
Blockedon: chromium:226931
Labels: todo-kbx
Status: Unconfirmed
Bulk reset for re-triage.
bulk edit for re-triage.
Labels: -todo-kbx
Adam and al: can you triage this one? Thanks.
Status: Assigned
Adam, do you think that webrequest support for websockets will be a fallout of your work on a new WebSocket stack?
Comment 21 by, May 13 2014
Labels: Cr-Privacy
Do you mean ?
If so, it is not supported from the original old implementation, IIRC.
Ah, sorry. I misunderstood the question at #20. Please ignore my comment at #22.
Yes, exactly. Mike received some external reports that are asking for this. I saw that Adam is the current owner and according to his teams page working on a new Web Sockets stack. So I was wondering whether the problem solves itself automatically. Otherwise, we should see what's necessary to get there.
Right. Old WebSocket stack doesn't use net::URLRequest to issue an opening handshake. OnBeforeRequest() hook of ExtensionWebRequestEventRouter is invoked in the ChromeNetworkDelegate. Events on URLRequest are intercepted by NetworkDelegate but SocketStream events are not.

The new stack uses the URLRequest.
Comment 26 by, May 13 2014
I haven't tested it personally, but in principle it should just work with the new stack.
What happens and should happen on other handlers, e.g. onComplete()?
Maybe the spec is not well defined for WebSocket, I think.
Good point, Takashi. We should draft some spec and discuss it with guys developing the extension.
I am happy to take a look at the spec. Thanks!
The old impl with 35.0.1916.153 (Official Build 274914) doesn't work.
The new impl with ToT doesn't work.
Comment 31 by, Mar 16 2015
Owner: ----
Status: Available
I think there are three levels of extension support we could add:

1. Basic interception of WebSocket handshakes, similar to HTTP. We probably should have this, but I don't know how to implement it. Maybe it should be opt-in, so that extensions which up until now haven't seen WebSocket requests don't accidentally start blocking them all?
2. Interception of data frames sent to/from the renderer. This would involve a brand new extension API. I don't know what the use-case would be.
3. The ability to implement WebSocket extensions in Chrome extensions. This would be prohibitively complex.
I think option 1 should be fine. That is basically what Firefox does. And would be sufficient for us - Adblock Plus. However, excluding WebSocket requests by default isn't necessary IMO. For example if an extension is blocking all kind kind of requests to, blocking WebSocket requests as well is probably the intended the behavior. And on the other hand if an extension only considers certain request types, it will just ignore WebSocket requests anyway, assuming there will be a new type indicating WebSocket requests.
I'm also in support of option 1. Like #32, I support opt-out and not opt-in. 

There are badware distributors "exploiting" (using the lack of implementation reflected in this bug) this to distribute potentially dangerous code to clients already. 
Comment 35 by, Nov 22 2015
Labels: -Pri-3 Pri-2
Upping priority to P2 due to active exploitation report from #34. It appears that fixing this may be as simple as changing HasWebRequestScheme() in //extensions/browser/api/web_request/ but verification is needed (and there ought to be a test to make sure it keeps working).

Comment 36 by, Nov 27 2015
Labels: Cr-Blink-Network-WebSockets
Comment 37 by, Nov 27 2015
Labels: -Cr-Blink-WebSockets
Issue 488100 has been merged into this issue.
Status: Assigned
Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.
Comment 41 by, Dec 24 2015
Is there any news here?
This feature would be great for user blockers (such as uMatrix, uBlock).
Comment 42 by, Feb 12 2016
Status: Available
Comment 43 by, Feb 12 2016
Owner: ----
Is there any news? Will this be fixed in near future?
Comment 45 by, Mar 16 2016
It's almost 4 years since this bug was open. Do you have plans on implementing/fixing it. This really anticipated feature in terms of network requests debugging.
Special chromebug for the distribution of advertising
Comment 47 by, Mar 22 2016 said:
There are badware distributors "exploiting" (using the lack of implementation reflected in this bug) this to distribute potentially dangerous code to clients already. 

Does anyone know an example of this exploit?
Maybe people will notice when real exploit happens in the wild
Look at the comment 46 right above yours. There are at least two examples of an advertisements being loaded this way.
@48 precisely. 

The failure to implement websocket intercepts means malvertising has an unimpeded path into our browsers. 

I know this bug is tagged privacy, but it's a serious security flaw given how popular it is to breach advertising networks for the purpose of distributing malvertising on large, popular websites.
Comment 51 by, Apr 26 2016
Someone reported that there is an advert network (rev defender) that use websocket to deliver advert when other methods are blocked (you can see it at
The discussion is at
Comment 52 by, Apr 27 2016
uBlock Origin has a workaround for this problem: they replace the WebSocket API with dummy code.
> they replace the WebSocket API with dummy code

There is no dummy code, it's wrapper code, which purpose is to allow uBO to become aware of WebSocket creation while keeping the functionality of WebSocket when they are not to be filtered.
This issue becomes more important day by day, because advert networks are turning to websocket as a way to evade various ad-blocking softwares.
Whether it is dummy code or wrapper code, they are bad because of chrome's multi-thread multi-process way.
If there is just a slight delay (eg due to a background process doing something), chrome may skip whatever the extension is trying to do or it will be inserted and executed too late meaning the script that use websockets have already been executed.

People have been talking about before-script-execution event and similar to try and solve this issue. Chrome dev team doesn't want to play ball as usual. It must be their motto: "We will not be co-operative at all!".
Comment 56 by, May 23 2016
From comment #35, this looks like a fairly simple fix.
>>> Upping priority to P2 due to active exploitation report from #34. It appears that fixing this may be as simple as changing HasWebRequestScheme() in //extensions/browser/api/web_request/ but verification is needed (and there ought to be a test to make sure it keeps working).

Can anyone from Chrome team verify this assessment?
Comment 57 by, Jun 27 2016
This loophole has already been used by an advert network (revdefender) to deliver advert or anti-adblock scripts.
It won't be long before malware starts using this vulnerability. Only then this issue will be acknowledged as a security problem.
I hope this will be fixed before too many people get hurt.
#57:  It's not a security problem for Ad networks to use javascript functions to deliver ads.

Malware that exploits security vulnerabilities in browsers should be addressed at the root, not by breaking core Javascript functionality.

uBlock Origin, Adblock Plus, etc., are breaking core JS functionality and presenting even more security issues by overriding basic JS functions.

It would be prudent for Chrome to implement a fine-grained permission model to allow or disallow extensions from overwriting core JS functionality so users can make informed decisions.

The adblock extensions which overwrite WebSocket() may introduce their own security issues or break other things and the user will almost certainly believe it to be the browser's fault.
Comment 59 by, Aug 17 2016
Adverts are a well documented vector for serving malware. That even has a name "malvertising" . To say that an open source wrapper for the WebSocket function is more of a security risk than these adverts seems crazy to me. (Of course I will be happy when the warppers are no longer required, but I'm not holding my breath there...)
Comment 60 by, Aug 17 2016
#58: While we're at it, how about a fine-grained permission model for what third-party domains the browser can connect to using what technologies, so that these kind of problems can be solved at the root if need be?

And I strongly disagree with your notion that there is only one point at which malware problems need to be solved. Content blockers *already* let the user make an informed decision, and they are an important tool in preventing the spread of malware, *even* if you discard the other reasons for blocking ads (such as not consenting to being manipulated).
routeh is working in advertising industry: 

"I am recovering over $1,000,000 / quarter in lost revenue from Adblock for my current employer. I have designed and implemented multiple strategies to combat Adblock."

yep, he's crazy.
> and the user will almost certainly believe it to be the browser's fault.

And the best part here: it actually will be "the browser's fault"! 'Cause if someone will manage to break through browser's security using wrapped around WS he will manage to do so without that wrapper at all.

...also, WS is not part of "core Javascript functionality".

WebSockets are core functionality.  Overwriting them without informing the user is unsafe.

Once upon a time, Android apps could be installed with a very coarse permission model.  Now, many individual items require user input approval.

It would make sense to adopt this same permission model for Chrome and Extensions, so users can make informed decisions about the extensions they're installing.

What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

How can non-technical users understand the risks presented to them from extensions which overwrite Websockets and perform their own logic on top?
I see, the advertising industry (the very dark part of this "industry") is very angry: they wont be able anymore to deliver malware using websockets.

What about the malicious ads / popups plenty of pages are trying to deliver to so-called non-technical users ? Are you also worried about them ?
> WebSockets are core functionality.
Nope, also you gave a link to WebSocket Protocol, not WebSocket object. JS have a couple of fundamental objects and WS is not one of these.

> What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

What would stop malicious extension from stealing your credit card data and show you third-party ads? If extension already have access to the page it can do whatever it want and rewriting WS is just a tiny fraction of that. You can modify the entire page as you wish, so malicious extension can simply add necessary code into the page scripts on the fly. It can log every your keystroke within a page and every single click. Some banks have a special on-screen keyboard with randomized button locations, but malicious extension can detect where you clicked and which number was that. So, separate permission for redefining stuff like WS won't help anyone and only add the confusion.
Comment 66 by, Aug 18 2016
#63: It is very telling that you are conveniently glossing over the problem of ability-to-block-ads, focusing on lobbying for removal of *current means* for doing that instead, despite that not being what this thread is about *at all*.

This is made even more questionable by the fact that you are employed at Mindgeek *specifically* in a role where you are responsible for *preventing ad-blocking*. You are evidently here to try and protect your business, rather than to argue security.

But I'll briefly entertain your question:

> What would stop a malicious extension from intercepting WebSockets requests, copying the data and sending it to a logging server?  How would you know?

Nothing. Just like for any other kind of software. Just like for scripts loaded on the page. I'm all for more granular permission models, but that's not what you're here to argue. You're trying to get the ability to block ads removed.

If you *truly* feel that there needs to be a more granular permission model for extensions, then please create your own issue on the Chromium tracker to argue that, and stop hijacking this one for your own interests.
Pornhub and many other adult sites ("Pornhub") are owned by MindGeek[1].

These sites currently deliver 3rd-party ads (including 3rd-party javascript code) through WebSocket connections.

In Chromium-based browsers, WebSocket requests do not go through the webRequest API (the present issue). So they can't be blocked, in practice they are "invisible" to an extension.

A blocker wrapping WebSocket on a Chromium-based browser gain the ability to block WebSocket-based ads served by Pornhub.

uBlock Origin ("uBO") currently does this through its companion extension uBO-WebSocket. uBO-WebSocket still has a relatively small user base.

The next version of Adblock Plus ("ABP") and AdBlock (which uses ABP's filtering engine) will gain the ability to block WebSocket's connections through wrapping.[2]

Adblock Plus + AdBlock together have tens of millions of users.

This is of course what really worries #58 -- only this can explain the nonsensical arguments put forth.


> A blocker wrapping WebSocket on a Chromium-based browser gain the ability to block WebSocket-based ads served by Pornhub.

Should really be:

> A blocker wrapping WebSocket on a Chromium-based browser gain the ability to disclose to the user, and to block WebSocket-based connections made by web pages served by Pornhub.

The ability to even just disclose to users these previously invisible connections is a big pro-users forward step.
Well, technically they wasn't invisible to the user. If you open page inspector and go to the Network tab they will be there and even marked as "websocket" type.
Comment 70 by, Aug 19 2016
yes, the wording is a bit confusing here.

Actually, in comment #67, he said that:
In Chromium-based browsers, WebSocket requests do not go through the webRequest API (the present issue). So they can't be blocked, in practice they are "invisible" to an extension.

Apologies, I would have understood an issue discussing WebSocket to be pertinent.

In any case, I have created an issue to track the idea of granular permission models for Chrome extensions here:
For book keeping, Chromium team has merged in to this ticket:

After reading this:

There appears to be a strong motivation on the extension side to ensure they can blacklist / whitelist network calls.  As a for-profit organization, I believe the only reason for this is for them to further profit from "Acceptable" programmes, similar to "Acceptable Ads". 

I can see an offering in the future for "Acceptable WebSockets", "Acceptable WebRTC", etc.
Comment 73 by, Aug 27 2016
#72: Please cut out the nonsense in this thread. The majority of content-blocking extensions are not commercial at all, and have no such programmes.

If you have a problem with AdBlock Plus or their Acceptable Ads programme, then take up the issue with them, and stop polluting this thread.
Comment 74 by, Sep 10 2016
#72 as a non-profit extension developer (Privacy Badger by EFF) I completely support #73 and gorhill's comments on this. Your arguments are inane. There is no security risk that is exacerbated by allowing extensions to block websocket requests beyond the already existant security problems of extensions. 
There are many quite legitimate reasons that adblocking and tracker blocking extensions want to intercept *all* network calls. Especially as long as your industry keeps using super cookies and fingerprinting to track users. I am sure you are well aware of this fact which is why you are here fighting so hard against this API.

Google devs, please pay attention to this issue, it is extremely important for all of us who are writing tracking protection software. 
Is anyone working on a patch for this?
Look at that empty "Owner" field at the top-left corner. Yet, that's it. :(
Hi everyone,

I've created a patch for this:
Not sure yet who should review the patch. Asked Dominic (battre@) and Takeshi (tyoshino@) to start with somebody.
+nasko and charlie - any security concerns with allowing extensions to intercept web socket requests assuming they have the proper host permissions?
Although not directly related to the "industry versus private (single) user" debate per se, this will have repercussions in what other programmers can dictate onto a browser's visitor.

It is a creative use to use/misuse/abuse WebSockets to attempt to bypass adblocking but it still remains an invasion of privacy nonetheless. So I can only agree with comment #73 and #74 and have to wonder about Comment #72 a lot. This is not solely about adblocking per se - it also is about what is deemed "permissible" by the google chromium team for third party content providers to dictate onto visitors and what kind of control the visitor will have over content sent to their browser(s).
@72 If a for-profit organisation is what it takes to ensure that ad-networks are doing their due-diligence when it comes to protecting consumers against malicious and invasive ads, then so be it.

The ad networks put themselves in this corner with their greed. If they spent even 1% of their revenue, ensuring that the ads run on their networks were SAFE to run, then we wouldn't be in this situation today.

Additionally, arguing for granular permissions, or against WebSockets in particular is nonsense. NoScript exists. Content-Blockers exist. Firewalls and Anti-malware products exist. This has NOTHING to do with breaking JS functionality, as there are far more integral parts to JS out there that are disabled by extensions as it stands.

Personally, I think ALL parts of the request stack should be configurable via extensions. Extensions themselves ARE the permission set that you speak of already, and I see no reason to go more granular than what we already have for web-requests, etc.
@77 provided a patch for review by Chrome team. Can Chrome team please review it? Thank you. 
Comment 82 Deleted
Project Member Comment 83 by, Feb 17
The following revision refers to this bug:

commit a7a2ee3f307090e4f5dd8848ce498c939993b3db
Author: pkalinnikov <>
Date: Fri Feb 17 12:39:54 2017

Introduce WebRequestResourceType.

WebRequestResourceType enumerates all resource/request types that WebRequest
API cares about.

There is a 1-to-1 mapping between WebRequestResourceTypes and their string
names. Helper functions are provided to get string representation for each
type, and vice versa.

Each content::ResourceType maps to a single WebRequestResourceType, while the
latter can correspond to multiple content::ResourceTypes, e.g., the OTHER type.
Note that this CL also makes 3 content::ResourceTypes (SUB_RESOURCE, PREFETCH,
and CSP_REPORT) map to OTHER explicitly (before they were indirectly considered

Some (so far only 1) types are not covered by content::ResourceType. For
example, the WEB_SOCKET type represents a WebSocket request, and corresponds to
URLRequests which have a ws/wss scheme. A helper function is provided to
compute type from a URLRequest in such a way that it takes both scheme and
content::ResourceType (if any) into account.

This CL also adds 'media' and 'websocket' types to WebRequest API.

BUG= 129353 

Cr-Commit-Position: refs/heads/master@{#451287}


FYI (in response to the commit description of a7a2ee3f307090e4f5dd8848ce498c939993b3db): CSP reports have always been mapped to the "ping" webRequest type (since internally CSP reports were flagged as ping by Blink).
CSP reports will be flagged as the (new) "csp_report" type once the patch for bug 637577 lands.
Project Member Comment 85 by, Feb 22
The following revision refers to this bug:

commit 0f198df6bc8da6fe51b34f11b50936700b6e9353
Author: pkalinnikov <>
Date: Wed Feb 22 11:11:24 2017

Support WebSocket in WebRequest API.

This CL makes WebRequest API support intercepting the WebSocket handshake
request. Since the handshake is done by means of an HTTP upgrade request, its
flow fits into HTTP-oriented WebRequest model. Additional restriction applies,
that WS request redirects triggered by extensions are ignored.

Note that WebRequest API does *not intercept*:
 - Individual messages sent over an established WebSocket connection.
 - WebSocket closing connection.

The |details| object reported to extensions uses the newly introduced type of
request: 'websocket'.

BUG= 129353 

Cr-Commit-Position: refs/heads/master@{#451991}


Status: Started
Hello everyone,

The fix has landed. I see a lot of interest here, so please try it out. Happy to receive feedback.
Labels: M-58
Status: Fixed
Marking as fixed. The feature is available starting from Chrome 58.
Comment 88 Deleted
Extra thanks to the team for making this to work for declarativeWebRequest too!!

Confused me a bit at first because redirections didn't work, but I found out this was by design.
#88 ( Raymond, did you delete your comment? I was going to respond that the feature is available from 58.0.3021.0. Did you make it work?
#90 I thought I just added noise to the thread and that I should wait to know which build for sure contains the fix. So I am on build 58.0.3026.3 (linux), and so far I have not been able to see websocket reported.
Alright, never mind, it works fine. I had forgotten one "tiny" detail: to add "ws://*/*" and "wss://*/*" to "permissions" in the manifest.

Thanks for your work.
Works for me in the Linux dev channel (58.0.3026.3), using the existing "<all_urls>" permission.
It seems that nobody thought about updating validation in Chrome Web Store. An upload fails right now:

  The manifest defines an invalid url: ws://*/*. (PKG_MANIFEST_PARSE_ERROR)
  The manifest has an invalid URL scheme: wss (PKG_MANIFEST_PARSE_ERROR)
+rdevlin.cronin@: Devlin, do you know how to address #94?
+James for comment #94 on CWS
Sign in to add a comment