Timeline for Why is the synchronizer token pattern preferred over the origin header check to prevent CSRF
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 4, 2019 at 10:43 | comment | added | light | I believe the bug has been fixed in FF. If you don't care about old browsers, the Origin header can actually be an adequate defence. Of course, this also depends on the server performing the correct checks, and that your server's API is designed well, e.g. don't allow state-changing requests using GET. | |
| Oct 26, 2018 at 15:15 | comment | added | SilverlightFox | @Xenos I don't think it is irrelevant because this makes it impossible to have an application that is secure against CSRF, even at this moment in time. Why wait for some future bug fix in a browser when you can secure your application now? For now use tokens until this is fixed. | |
| Oct 26, 2018 at 13:30 | comment | added | Xenos | @SilverlightFox It's still irrelevant IMO since the bug is actually fixed, and even if it's not, then it's a browser bug, so you must fix it in the browser, not in every single web application. | |
| Oct 26, 2018 at 11:48 | comment | added | SilverlightFox | @Xenos That is a good point. However, at the time of writing there exists bugs in current implementation of the origin header in that e.g. Firefox does not send this header with POST requests. My answer updated. | |
| Oct 26, 2018 at 11:47 | history | edited | SilverlightFox | CC BY-SA 4.0 |
Updated regarding POST bugs
|
| Sep 26, 2018 at 8:14 | comment | added | Xenos |
Does it make sense, when it comes to web security, to consider that "browser can be old"? Non-last-version of browsers should be discarded from security plans. In other words, if we don't consider "old browser" as an issue (it's user/client's responsibility), then is there a reason to not use HTTP: Origin as anti-CSRF mechanism?
|
|
| May 23, 2017 at 12:40 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Sep 28, 2015 at 7:32 | comment | added | jakub.g | On the other hand, for an existing application, the CSRF token way is backward-incompatible: all the clients would have to be updated, or they will instantly break the moment the server starts blocking the requests without token. It might be a stopper for certain scenarios (or, one could do a gradual roll-out: first implement the token exchange between the server and clients, but not enforce token validation on server only after high enough percentage of clients have been updated). By clients, I mean clients of the API; for instance, hybrid mobile apps. | |
| Jun 10, 2015 at 5:46 | vote | accept | Michael | ||
| Jun 9, 2015 at 13:30 | history | answered | SilverlightFox | CC BY-SA 3.0 |