Re:Securing your API: a modern alternative to CSRF tokens
by homakov on Tuesday June 13, 2017 @06:30PM
(#14549220)
If I were to drop CSRF tokens (which work reliably) I would go directly to Origin verification. No Referer. Something in the middle is worst of both worlds.
[ Parent
| on HN ]
Re:Securing your API: a modern alternative to CSRF tokens
by skeggse on Tuesday June 13, 2017 @07:09PM
(#14549442)
I'm curious about your comment. We (attempted) to address cases where we needed to infer the Origin from the Referer due to incomplete browser support. What about using both makes this necessarily worse, when the use of the Referer is really only a temporary bandage for said incomplete support?
Re:Securing your API: a modern alternative to CSRF tokens
by homakov on Wednesday June 14, 2017 @03:45AM
(#14551248)
Worst because it is neither proven as tokens which are used for decades already nor as convenient as simply whitelisted Origin and you even offer an extra dependency. Are those scenarios without Origin important? Like ff for form request - you can use xhr there and drop referer support entirely.
Re:Securing your API: a modern alternative to CSRF tokens
by skeggse on Wednesday June 14, 2017 @12:11PM
(#14553716)
You're right, support for cross-origin form POSTs isn't important for us. What is important, however, is same-origin requests, and Firefox doesn't send the Origin header with those. For us, the Referer serves its most important role by indicating where those requests originate from.
EDIT: when Firefox _does_ start sending the Origin header, we may drop the Referer - we'll see.