Re:Why do we have both CSRF protection and CORS?
by smagin on Sunday March 02, 2025 @05:44PM
(#43236053)
"search this site in google" shouldn't even be a POST request, but yeah, when we'll have better defaults for cookies it should work nicer. And if you are a web developer, you should check your session cookie attributes and explicitly set them to SameSite=Lax HttpOnly unless your frameworks does that already and unless you know what you're doing
Re:Why do we have both CSRF protection and CORS?
by Muromec on Sunday March 02, 2025 @06:08PM
(#43236264)
It was GET request, but the point is -- you can make the request from the browser to a different domain by making a form. With JS and DOM you can make a hidden iframe and make the request without user initiating it or noticing even, but in both cases you don't get to read the result.
Then you can make the form make post requests by changing a method. Nothing wrong with this either -- the browser will navigate there and serve the page to user, not to the origin server.
What makes it problematic is the combination of cookies from the destination domain and programmatic input or hidden field from the origin domain. But the only problem it can cause is the side-effects that POST request causes on the back end, as it again doesn't let the origin page to read the result (i.e. content doesn't cross the domain boundary).
Now in the world on JS applications that make requests on behalf of the user without any input and backend servers acting on POST requests as user input, the previously ignored side-effects are the main use and are a much bigger problem.