Stealing Secrets from Developers Localhost Development using Websockets

I came across this article that have some disturbing facts about using websockets from javascript in the browser for port scanning your machine.

The author discovered this after reading another article about why Ebay is port scanning localhost via websockets.

So this made him wondering how far he could go, and he starts with this question:

This got me thinking. I know that popular JavaScript frameworks use websockets in development to automatically reload pages when content changes. Could a malicious website eaves-drop on that traffic, and find out when developers are saving their code?

The reality was slightly worse than I had thought.

And then finds this disturbing facts:

But what happens when the developer makes a typo? The webpack dev server helpfully tries to send a bunch of debugging and stack information to the developer’s screen, by way of its websocket connection.

Now things are getting juicy. We’ve got code snippets, paths to files, locations, all sorts of bits of useful info.

It gets even better if eventually the Dev accidentally typos on a line containing useful data:

Now we’ve got a copy of this developer’s AWS Dev credentials. Quick, fire up the bitcoin miners!

What are your thoughts on this? Did you ever imagine that this could get so far?

I really need to do a POC of attacking Phoenix WebSockets, because more I read about them, more concerned I get with using them.


I did imagine it will go this far, yes. The insanity that is serving you code (JS) which your browser – which is essentially a small OS – executes almost without scrutiny, mandated that one day this will happen.

As excited as I am for some tech innovations – WebSockets included – we definitely need to get back to basics and even the drawing board for a lot of stuff.

But there’s no funding for that so I predict a lot of very embarrassing security incidents will keep happening for years to come.


On the other hand - the only way to find out all the edge cases and make it better - is to use it. Even the best mind of the world can’t think of all things that can go wrong. Every single invention in human history had issues, but it was improved and made better.

So please do some tests if Phoenix Websockets can be exploited and create an issue if it is the case.

1 Like

Don’t interpret my post as a complain about Phoenix websockets, I am just trying to raise awareness :wink:

And yes If when I get time to do the POC and I found an issue I will let Chris McCord know about them :slight_smile:

Skimming the article, the author is using an external site that has js connect to localhost, right? If so, changing check_origin: false to check_origin: ["myapp.local"] in dev.exs with a host file entry would suffice to prevent another host from establishing a websocket connection to your local server.


PSA: Do not use .local for your local development domain. It is reserved for mDNS and you should use .localhost which is currently reserved but unassigned to anything.


I use .test mainly because it’s a bit less to type than .localhost. (In conjunction with puma-dev to route foo.test to the right port)


I have plans for creating similar tool that will be language independent and will automatically create TLS certificates using local CA.

1 Like

I had .dev initially but I thought someone would call me out for it being a real tld now, but I failed on my 2nd choice :smiley: In general I still use .dev, but good to know about mdns!

1 Like

.dev has few other “problems”, for example enforced HSTS in Chrome, not mentioning people using it as their TLD (like me).

What is the reason behind having check_origin: false in developments? Why not keep it as in production?

Also some protocols work in dev only when using .localhost. For instance WebAuthn requires TLS with the exception of the .localhost domain so that you don’t need to enable TLS in dev.


I am curious if this attack can’t be stopped using ssl certificates on the following stack:

phoenix (ssl certificate)
nextjs(react SSR lib)

1 Like