I know there are now WebSockets, but what is the issue with providing a socket API to allow interacting with existing protocols?

I mean, after all, I can use a hidden flash object to do the same already. Is there an attack vector I am missing?

  • 2
    Consider researching the same-origin policy. Voting to close.
    – rook
    Sep 22, 2015 at 5:37
  • 2
    "I mean, after all, I can use a hidden flash object to do the same already": except that Flash is now disabled by default (when it is available) while JavaScript is enabled by default (and widely available). Sep 22, 2015 at 9:37
  • 7
    Voting to reopen. The question is obviously asking about a security aspect. And simply referring to same-origin policy as proposed by rook does not fully answer the question. Jan 30, 2018 at 5:39

3 Answers 3


... but what is the issue with providing a socket API to allow interacting with existing protocols?

This is not a restriction of the language itself but of it's use inside the sandbox within the browser. Just imagine that a script somewhere on the internet gets loaded into the browser and could from inside the browser access every computer reachable by the browser with arbitrary protocols. You could easily misuse this to send spam through a companies internal mail server or attack/misuse other internal and external resources.

Which means there must be some restrictions in place and the different sandbox environments for the different language runtimes provide different kind of restrictions:

  • With flash the target host must explicitly allow access to by providing an appropriate socket policy file. This is similar to the mechanism within HTML5 CORS.
  • Untrusted Java applets are limited to communication with the host providing the applet.
  • And with JavaScript inside the browser you can talk to almost all sites, but you are limited by the protocol you can use, i.e. HTTP (restricted by CORS) and WebSockets.
  • 1
    I totally missed the point of flash policy files. Thanks! Sep 23, 2015 at 9:26
  • I know this is a bit old topic, but I'd really like to discuss it a little more. Can't something like flash-like socket policy be implemented for JS? It would indeed be extremely powerful to be able to use plain sockets directly from web browser.
    – Mikz
    Mar 19, 2020 at 10:39
  • @Mikz: This is a Q+A site and not a discussion forum. Questions should be asked as such and with all necessary context instead as comment to a more than 4 year old answer. Mar 19, 2020 at 12:34
  • 2
    @steffen-ullrich: I just wanted to point that this question isn't answered fully and without a doubt. It's been stated that it's unsafe and yet examples of how others have made it safe were provided. So imo the main question hasn't been really answered.
    – Mikz
    Mar 23, 2020 at 14:19

I'm not sure what socket API access a Flash object provides, but there are very good reasons to not allow plain TCP or UDP (much less any other kind of) sockets in JavaScript.

The biggest one, probably, is that you're basically providing a way to bypass firewalls if you do that. Every service on your machine that listens on loopback network sockets, normally unreachable by external attackers, can now be attacked from the browser. Every machine on your network, normally isolated from the Internet by your gateway and firewall, can now be accessed or attacked by Internet code.

There are other reasons, too. Port scanning and DDOS attacks become much easier when browsers can do them without so much as a plugin (yes, browsers can attempt to launch DDOS on HTTP(S) servers, but they could be much more efficient with lower-level sockets). Network worms (especially those that only a small proportion of machines are vulnerable to) can propagate much faster when everybody who views an ad on a popular website starts sending out attacks, instead of just those who actually get infected.

Websockets exist to give a way to do socket communication with things that explicitly want to communicate with a browser that is running untrusted code. The typical Internet server is similarly hardened, expecting malicious clients of all stripes. The problem comes from services that are not expecting malicious traffic, because they're only reachable by trusted clients. JS-controlled sockets would totally break that.


The browsers equivalent to a typical TCP socket is the WebSockets API spec.

If you want sockets in JavaScript take a look at the socket API in node.js

  • 1
    I am already aware of this. However I question why websockets were needed in the first place, and what security risks it would imply if, lets say the socket api of node was available in the browser. Sep 22, 2015 at 1:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .