Timeline for Should I use CSRF protection on Rest API endpoints?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 13, 2018 at 1:54 | comment | added | Sebi2020 | Yes State Transfer, that's the important point. The state isn't stored on the server side. The client tells the server about his state. And CSRF makes only sense if the api is accessible through regular web browsers. Some http methods like DELETE, PUT/PATCH are not even supported by todays browsers which makes the api only accessible to stand-alone http clients. | |
| Aug 7, 2017 at 17:40 | comment | added | Conor Mancone | I absolutely agree with you. It wasn't my desire to quibble over terminology. Part of the problem is that I wasn't clear enough in my original question: I was specifically talking about client state, not application state. | |
| Aug 7, 2017 at 16:13 | comment | added | John Wu | Well I'd rather answer the question than quibble over terminology. But the S in HATEOS and the S in REST both stand for state. As long as client state isn't held on the server I don't think you've "violated" the spirit of the REST approach. | |
| Aug 3, 2017 at 20:44 | comment | added | Conor Mancone | If you disagree with part of my statement I would be happy to hear it. IMO, statelessness is a central goal of REST APIs. Sessions definitely make an API stateful. Cookies... technically I suppose you could use cookies and not be storing state server side, depending on how you use them. | |
| Aug 3, 2017 at 20:28 | history | answered | John Wu | CC BY-SA 3.0 |