> This only affects servers that do indeed serve the "anybody can talk to me" CORS headers.
Again, even if these CORS headers are not sent, the browser still does a request to the server in order to find out whether the headers are being sent. Check running python3 -m http.server in your terminal, and then do var v = fetch("http://localhost:8000/hellllllo") in your browser's console. You will get a big red CORS error in the console, because the builtin python http server does not send these headers. But the web server will still receive and respond to the "hellllllo" GET request! It will show up in your terminal's log. For some insecure servers, getting a specifically crafted request might be enough to exploit security bugs. Like I said, take a server that has a limited size buffer for the URL after which it overflows letting you write data to whatever is beyond that on the stack.
> This change doesn't actually increase this risk
Alright you have a point here, but it's still bad this feature exists in the first place.
> This is a pretty common pattern for lots of popular software that has a desktop component
Because it's used doesn't mean it's a bad idea.
> There's ongoing work to restrict this further
Huh that's very nice. Indeed this would resolve my concerns:
In the future, whenever a public website is trying to fetch resources from a private or a local network, Chrome will send a preflight request before the actual request.
Preflight requests are hardcoded and barely have any attacker controlled data (except for the ip address maybe, as 127.0.0.2 is as valid as 127.0.0.1).
Again, even if these CORS headers are not sent, the browser still does a request to the server in order to find out whether the headers are being sent. Check running python3 -m http.server in your terminal, and then do var v = fetch("http://localhost:8000/hellllllo") in your browser's console. You will get a big red CORS error in the console, because the builtin python http server does not send these headers. But the web server will still receive and respond to the "hellllllo" GET request! It will show up in your terminal's log. For some insecure servers, getting a specifically crafted request might be enough to exploit security bugs. Like I said, take a server that has a limited size buffer for the URL after which it overflows letting you write data to whatever is beyond that on the stack.
> This change doesn't actually increase this risk
Alright you have a point here, but it's still bad this feature exists in the first place.
> This is a pretty common pattern for lots of popular software that has a desktop component
Because it's used doesn't mean it's a bad idea.
> There's ongoing work to restrict this further
Huh that's very nice. Indeed this would resolve my concerns:
Preflight requests are hardcoded and barely have any attacker controlled data (except for the ip address maybe, as 127.0.0.2 is as valid as 127.0.0.1).