ant to change the state on the server and can be misused. So there should have been a preflight request for the above CORS POST request, but browsers did not do such thing in the above demo.
The reason for this boils down to what is allowed vs not allowed prior to HTML5 specs. In HTML4, we could do cross origin requests using <img src=’…’>, <script src=’…’>, <form method=”GET/POST” action=’…’> etc. Following the same rules, cross origin GET requests and some POST requests can still be done using CORS. So what are those “some” POST requests? These are nothing but what we have seen above in the form submission case. i.e., POST requests with various form content-types. Other than these, any sort of POST request will require a preflight request, which is the security enhancement in CORS.
HTML Forms and CSRF attacks go hand in hand. What about CORS & CSRF?
Yes, CSRF attacks using HTML forms are quite popular and one of the well known defenses is sending random, unique nonce in every request. Since CORS POST requests mimic HTML form requests, they can be victims of CSRF attacks and hence every CORS POST request should use CSRF defenses. If this is not considered seriously, it paves way to a number of stealth attacks such as silent file uploads. In the first snippet, if you set “xhr.withCredentials=true”, even cookies can be sent in the POST requests and hence replay attacks can be done.
Winding up the show, CORS is beautiful and enhances the modern web interactions in many ways. We already know how bad the state of AJAX security has been, owing to poorly written code. If CORS is studied as ‘yet another new thing on the web’, without understanding the internal details, web applications will suffer big time leading to serious attacks. Time to focus on the security aspects of modern web specifications! No escape!!
Update: You may check the source code of the demo used in the article here: https://github.com/novogeek/AJAX-vs-CORS