Everything you load from someone else is one less thing you need to host yourself. The literal cost (and risk of downtime) of hosting may be small, if you're already hosting your own HTML etc, but we should also count as a complexity cost just having those files in your repositories or on your severs where developers are working.
This one is ...
Does Chrome solve some kind of vulnerability by not allowing me to do what I am trying to do which would not have been possible to solve in any other way other then completely preventing me from doing what I am trying to do?
Yes, it does.
If web pages loaded from file:// were allowed to make requests to other pages under file://, they would be able to read ...
I've identified the issue. The CORS settings don't allow "withCredentials" as the server doesn't respond with Access-Control-Allow-Credentials: true, which is why the POST request isn't made.
Furthermore, as stated by @Matthew, with a wildcard for Access-Control-Allow-Origin, the Authorization header can't be sent.
You don't need an AJAX request, the standard approach to exploit this issue would be:
<form id="myform" method="post" action="http://mysite.vulnerablesite.com/mysite/deleteUser" >
<input type="hidden" name="userId" value="5">
Validation / sanitizing is done on server only. In your example there is no server side code.
If your client loads files that should be available to everyone without any restriction, then there is no need on server to check anything. I.e. you don't have to do anything on the server.
"anyone could just make the simple call anyways" - this is wrong statement. ...
With a normal CSRF attack, only Simple Requests are vulnerable. Those docs detail the requirements for a "simple request", but a request that uses content-type of "text/x-gwt-rpc" is not a simple request.
Although traditional CSRF attacks can only exploit simple requests, you can use Flash to exploit "complicated requests". The attack is more complicated, ...
tl/dr: For a game you are working on for fun with no one else's
information at risk then sure - do whatever makes your life easiest. You're
welcome to balance security and usability however you want as long as
you aren't risking other people's information. What you are doing
certainly isn't uncommon. However, this decision does in fact prevent
The risk is you have enabled code execution from the eval tag if an attacker can get content into it. You trust the content so that not be an issue but as mention it is a design flaw and laziness. Laziness leads to bugs and security issues.
Content Security Policy is very specific to stop what you are attempting here and their are multiple good ways to ...
From a security perspective the answer is to never send anything you don't want the user to know to any system the user controls.
From a UX perspective, having a bunch of extra data that's only visible if they open developer tools shouldn't be a problem. Anything they see in developer tools isn't "user experience", it's developer experience. Having stuff ...
The domain attribute of for a cookie cannot be set to arbitrary domains. While foo.example.com could set a cookie to example.com it could not set a cookie to example.org since this is an unrelated domain. From MDN:Set-Cookie: Invalid Domains:
A cookie belonging to a domain that does not include the origin server should be rejected by the user agent.
CORS is layered over HTTP so it makes somehow no sense to deal with CORS besides http https chrome and chrome-extension since the last 3 probably (I lack doc here) relies over the same rules as HTTP.
Any other protocol behavior for CORS is undefined for now. So Chrome blocks it.
To answer each question individually:
1) No, they just consider that since ...