I think that most browsers default to SameSite=Lax (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite), so you could still do a CSRF attack via a GET request / top-level navigation, although that’s only if you’ve coded your application to *do* things in a GET request.
If you explicitly use SameSite=Strict, then I suppose that CSRF protections could probably matter less. I hadn’t actually thought about that until now. I wonder about CSRF attacks that don’t require cookies. It’s been a few months since I’ve chatted with security experts, but I think I was advised to ensure CSRF protection as well as secure strict cookies. David Cook Software Engineer Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Online: 02 8005 0595 From: [email protected] <[email protected]> On Behalf Of Sebastian Riedel Sent: Wednesday, 4 November 2020 4:10 AM To: Mojolicious <[email protected]> Subject: [Mojolicious] Re: csrf vs testing These CSRF protection features are mostly legacy features these days for backwards compatibility. Now we have SameSite cookies, to which modern browsers default. -- sebastian -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected] <mailto:[email protected]> . To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com <https://groups.google.com/d/msgid/mojolicious/6cce769b-2b91-4532-aa01-cf5cc58a0d5bn%40googlegroups.com?utm_medium=email&utm_source=footer> . -- You received this message because you are subscribed to the Google Groups "Mojolicious" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/mojolicious/056801d6b3c4%244d1b8760%24e7529620%24%40prosentient.com.au.
