Live data from Hacker News

Securing your API: a modern alternative to CSRF tokens

mixmax.com

11–20 of 58 posts

Re: Securing your API: a modern alternative to CSRF tokens

#11
post #9

Why make an extremely complicated set up, with many edge cases, all to save yourself from a single token? - Privacy extensions often times block referrer headers. - POST requests are usually necessary. - Open redirects are common bugs, and getting your website to initiate one can be a problem. - Disabling CORS also relies on you killing crossdomain.xml, which you might overlook. Instead you can just roll out CSRF tok…

I believe the point of the article is that tokens don't get sent for HEAD or OPTIONS requests, and it's very possible that your API/server are still performing some sort of action on such requests. Or even if not performing a specific action, it still needs to be dealt with and hence is a DDOS vector.

Re: Securing your API: a modern alternative to CSRF tokens

#13

What stops a user from writing a simple HTTP client to spoof the header?

Then that user can only 'hack themselves'. CSRF is a security vulnerability is because you can do a HTTP request on behalf of someone else, on someone else's browser, in someone else's session/security context.

Re: Securing your API: a modern alternative to CSRF tokens

#17

I don't really like the word secure next to CORS; you're relying on the browser to be secure... which it is not.

You are totally correct. CORS also falls apart if the client isn't a browser.

But, CSRF is inherently a browser vulnerability.

Re: Securing your API: a modern alternative to CSRF tokens

#20

The author admits that this solution won't work for "older" browsers. Which browser versions specifically?

https://caniuse.com/#feat=cors and hit "show all"

TL;DR - evergreen browsers, mobile browsers (except for images), IE 11+, and IE 8+ partially supports it

Post reply on HN