4 ms·

And just that had so many security implications, a boatload of security features and restrictions were implemented: being unable to access information about a r

And just that had so many security implications, a boatload of security features and restrictions were implemented: being unable to access information about a remotely loaded resource (like an image) from JS, CORS, etc. Additionally things like form elements being able to POST to any address still is something everyone else needs to be aware of and protect against.

vbezhenar 4y ago
While there will certainly be a security implications, software is written to enhance capabilities and security must support software and not the other way around. There will be new ways to DDoS but as it's already possible fill bandwidth on any TCP port, I don't think that it'll be drastic. IMO main reason behind CORS is to send request with cookies to another domain. If you can send arbitrary queries from JS but you still not have access to cookies for that domain, it's not really adds obvious attack lines. Yes, you'll be able to issue arbitrary GET requests and read responses, but I never understood why is it a problem in the first place.
- chmod775 4y ago
  > but I never understood why is it a problem in the first place. You can trivially find information on why all the security features that fall under the same-origin policy exist and what kind of vulnerabilities they prevent. I will not be repeating all that here. Most of these protections were added because actual exploits were demonstrated or found in the wild. They weren't added willy-nilly. I'll just leave you with some reasons for not even allowing reading response of cookie-free cross-origin GET requests: You don't want websites to turn their users into web-scrapers or even use them to brute-force logins on another site that happens to use GET for some API endpoint. Maybe they'll even try some IP-addresses that often lie in personal or company intranet. Is the HTTP control page of your cheap printer not password protected? One GET request later the attacker's website is downloading your recent print jobs. You're likely not the only to whom these are not obvious, because some of the attacks possible really aren't obvious. Be glad browser vendors are watching out too.

vbezhenar 4y ago

While there will certainly be a security implications, software is written to enhance capabilities and security must support software and not the other way around. There will be new ways to DDoS but as it's already possible fill bandwidth on any TCP port, I don't think that it'll be drastic. IMO main reason behind CORS is to send request with cookies to another domain. If you can send arbitrary queries from JS but you still not have access to cookies for that domain, it's not really adds obvious attack lines. Yes, you'll be able to issue arbitrary GET requests and read responses, but I never understood why is it a problem in the first place.

chmod775 4y ago
> but I never understood why is it a problem in the first place. You can trivially find information on why all the security features that fall under the same-origin policy exist and what kind of vulnerabilities they prevent. I will not be repeating all that here. Most of these protections were added because actual exploits were demonstrated or found in the wild. They weren't added willy-nilly. I'll just leave you with some reasons for not even allowing reading response of cookie-free cross-origin GET requests: You don't want websites to turn their users into web-scrapers or even use them to brute-force logins on another site that happens to use GET for some API endpoint. Maybe they'll even try some IP-addresses that often lie in personal or company intranet. Is the HTTP control page of your cheap printer not password protected? One GET request later the attacker's website is downloading your recent print jobs. You're likely not the only to whom these are not obvious, because some of the attacks possible really aren't obvious. Be glad browser vendors are watching out too.