This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This currently works in all browsers supporting CORS: * Setup a local web server such that cannot be accessed remotely. It responds with Access-Control-Allow-Origin: * for everything. * Load up a remote web app, say app.nczonline.net. * Inside of the web app, make an Ajax request to http://localhost:1234/resource There's nothing in the spec that says it shouldn't work, and so it does. The question I had is if this was an oversight (and therefore a bad idea to take advantage of) or a supported feature of CORS (in which case it's safe to assume it's not going away in the future). It seems like the question of whether or not remote resources should ever be able to access local resources is a higher-level security concern that needs to be addressed in the spec in some way.
So what is we want to do here? If URLs are not same-origin, and the target URL's host is "localhost", return a network error?
Say I'm developing locally, and I have a local version of some API for testing purposes, would jakearchibald.dev (which maps to localhost) be able to reach localhost:3000? Would jakearchibald.dev be able to talk to jakearchibald.dev:3000?
(In reply to Jake Archibald from comment #2) > Say I'm developing locally, and I have a local version of some API for > testing purposes, would jakearchibald.dev (which maps to localhost) be able > to reach localhost:3000? > > Would jakearchibald.dev be able to talk to jakearchibald.dev:3000? My expectation here would be that localhost (as a name) would be blocked, as would explicit access to 127.0.0.1 or ::1. Possibly, likewise for explicit access to the user's IP. But names mapping to loopback would not be affected so jakearchibald.dev could talk to jakearchihairy.dev.
Further idea, based on discussion at: http://krijnhoetmer.nl/irc-logs/whatwg/20140527#l-237 If the origin that is making a request to localhost (or any other explicitly local address) is itself one that is local (either explicitly or because its domain maps to loopback) then that request is subject to the usual processing, CORS and all. If however that origin maps to any other IP, access to explicit local addresses is just blocked. This should block the attacks from arbitrary sites, while making it possible for developers to hack things locally without getting unexpected blocking behaviour for localhost.
Mike, should this be a duplicate of bug 22262? From public-webappsec it seems like this is MIX territory now.
Yeah, it makes sense to pull this (along with the RFC1918 IP address restrictions) into the mixed content spec. I'm working on that, so I'll grab this bug.
What's the latest on this?
(In reply to Anne from comment #7) > What's the latest on this? The latest is that the RFC1918 restrictions got pulled out of MIX because of disagreements, and there's no good home for them at the moment. I'd still like to make them happen, but WebAppSec wasn't enthusiastic about going along with me because of IoT concerns and etc. It's been on my "nice to do" list for Chrome for months now, but I haven't made time to understand enough of the network stack's decision-making process to get the data I need in the places I need it. *shrug* Status: Pending, I guess.
Nicholas, it seems like the answer to your question is that you should be wary about relying on this, but that we haven't really sorted out where that should be specified. Mike, can we track this issue elsewhere since I'd like to eventually close off Fetch bugs in favor of GitHub and it seems like this is no longer a Fetch issue per se.
(In reply to Anne from comment #9) > Nicholas, it seems like the answer to your question is that you should be > wary about relying on this, but that we haven't really sorted out where that > should be specified. > > Mike, can we track this issue elsewhere since I'd like to eventually close > off Fetch bugs in favor of GitHub and it seems like this is no longer a > Fetch issue per se. Sure. This can live somewhere in w3c/webappsec. There hasn't been appetite to push this there in the recent past, but I'd like to try again.
https://lists.w3.org/Archives/Public/public-webappsec/2016Jan/0000.html https://mikewest.github.io/cors-rfc1918/ No need to track this here anymore.