I don't think that solves the underlying problem of side effect-ful/dangerous GET requests that may be easily exploited via CSRF attacks. You really don't want to expose POST/PUT/DELETE actions via GET.
Avoiding GET requests is not a fool proof way to mitigate CSRF. If your website has just one XSS vulnerability an attacker can send POST requests. It's much better to use some kind of token that is always sent with your forms.
And if you have zero XSS vulnerabilities, they may be able to trick users into interacting with a form on a site they control (the "CS" of "CSRF"). CSRF token is definitely necessary.
There's nothing stopping anyone from sending POST requests to wherever he wants, even without an XSS. the same-domain origin policy only forbids you from reading the response, not from sending the request. CSRF-wise, POST requests are just as vulnerable as GET requests.
Also, if someone does manage to find an XSS vulnerability, using a CSRF token won't be any good - the attacker can simply read the token from your website and use it.
No. Before performing a POST/PUT/DELETE or any other method with side effect to another domain your brother will issue an OPTIONS to get authorization first and will never perform the request if the server do not authorize it.
Then if your authentication is cookie based and you allow to delete resource via GET then all the attacker have to do is to insert <script> or <img> tag on any other domain with the proper src attribute to delete your content silently.
These endpoints are a VERY bad idea and are absolutly not REST. RESTful do not mean CRUD.
`<form>`s are allowed to send POST requests to wherever they want, without any restrictions. By creating a form that points to another domain, and automatically submitting it, you can send a POST request to wherever you want [1].
POST requests can be easily sent cross-domain. NO ONE SHOULD EVER think that just because he's not using GET requests he's safe from CSRF attacks.
EDIT: Just to clarify - I'm not saying that exposing those endspoints via GET is a good idea, I think its horrible. But people should be aware that avoiding GET does not protect against CSRF, and you still have to use CSRF tokens.
Hi nadaviv, if you don't want to expose those endpoints via GET, you don't have to. Those are set up that way in development so it's much easier to get started. You have full control over your routing table and access control policies.
How common are CSRF attacks? My sites are not protected at all but I don't know if it's worth the hassle to fix. It just doesn't seem like a big deal and very unlikely to happen.
