Here's a question I've had for a while: WHY in the world do web browsers not block access to localhost? What exactly is the extremely compelling use case that has prevented them from blocking this?
replies(6):
I'm not talking about UIs hosted on local web servers being able to send requests to themselves, I'm talking about UIs hosted on REMOTE web servers being able to send requests to local ones. It seems far worse than a random cross-origin request to me and for the life of me I can't imagine uses cases.
Maybe browsers should assume a CORS deny all unless otherwise specified?
What is a local webserver? Running on your machine? Running on your LAN? Running on your corporate intranet? How should a browser differentiate between these things?
What qualifies as a remote server? Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)? Just because something appears to be on a public address doesn't mean it actually is.
> Did you know, some very large enterprise environments squat on public IP's for private intranet internally due to address space exhaustion (IPv4 anyway)?
Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.
> Sucks to be them. If they've exhausted their private use IPv4 addresses, they can either rest comfortably knowing that NAT and IPv6 can solve their problem or they can ignore IETF recommendations and build a card house network that breaks if you give it a stern look.
This will only lead to organizations running IE7 (or whatever outdated IE version is most common now) forever.
[Error] Failed to load resource: Origin http://http.jameshfisher.com is not allowed by Access-Control-Allow-Origin. (localhost, line 0)
It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it.
So let's let perfect be the enemy of good? What's the logic here? Let's leave a huge security hole because we can't achieve perfection in all scenarios?
> It's also entirely possible you have some development api running on a particular port on localhost, and some app running in a container or VM that wants to make calls to it.
The VM should be on localhost or you should jump through a few hoops to whitelist it somehow. I see no reason why this should be allowed by default.
The logic here is don't hastily start implementing changes to how http requests currently work without a well established plan for doing so. I think there would be a good deal of corner cases you need to account for to successfully implement this feature.
Anyway, this problem seems pretty obvious, and I'm sure this discussion has been had elsewhere already.
As if the point of this thread was to push browser vendors to hastily implement this without thinking it through? Are you just trying to find something to have an argument over? I'm tired of this.
My preferred solution would be not to use web browsers at all, but our preferred solutions are much harder to make a case for than a simple security policy.
> This will only lead to organizations running IE7 (or whatever outdated IE version is most common now) forever.
In general, let's let them make that choice, but this could be configurable in the browser in the same way Javascript and cookie policy exceptions are handled.