To prevent WebSocket from being abused to attack existing HTTP servers from
malicious non-simple cross-origin requests, we need to have WebSocket
clients to do some preflight to verify that the server is not an HTTP
server that don't understand CORS. We could do e.g. when a custom header is

(a) the client issues a CORS preflight to verify that the server does
understand CORS and it is willing to accept the request.
(b) the client issues a WebSocket preflight to verify that the server is a
WebSocket server.

(a) may work, needs change on the WebSocket spec to ask WebSocket servers
to understand CORS preflight. It's not required for now.

(b) may be implemented by issuing an extra WebSocket handshake without the
custom headers but with Sec-WebSocket-Key, etc. just for checking that the
server is WebSocket server, but this may be not no-op to the server. So, I
think we should specify something new that is specified to be no-op.

So, anyway, I think we need to make some change on the WebSocket spec.


On Thu, Feb 5, 2015 at 10:23 PM, Florian Bösch <> wrote:

> Well,
> 1) Clients do apply CORS to WebSocket requests already (and might've
> started doing so quite some time ago) and everything's fine and you don't
> need to change anything.
> 2) Clients do not apply CORS to WebSocket requests, and you're screwed,
> because any change you make will break existing deployments.
> Either way, this will result in no change made, so you can burry it right
> here.
> On Thu, Feb 5, 2015 at 2:12 PM, Anne van Kesteren <>
> wrote:
>> On Thu, Feb 5, 2015 at 1:27 PM, Florian Bösch <> wrote:
>> > CORS is an adequate protocol to allow for additional headers, and
>> websocket
>> > requests could be subjected to CORS (I'm not sure what the current
>> client
>> > behavior is in that regard, but I'm guessing they enforce CORS on
>> websocket
>> > requests as well).
>> I think you're missing something. A WebSocket request is subject to
>> the WebSocket protocol, which does not take the same precautions as
>> the Fetch protocol does used elsewhere in the platform. And therefore
>> we cannot provide this feature until the WebSocket protocol is fixed
>> to take the same precautions.
>> --

Reply via email to