With the Same-Site attribute set to 'lax' by default on cookies, many argue that CSRF (Cross-Site Request Forgery) attacks may no longer be a threat, especially if modern web applications primarily use safe or idempotent GET requests. However, if malicious JavaScript runs in a browser and tries to execute cross-origin GET requests, these are blocked due to the browser's Same Origin Policy (SOP). If a malicious POST request is fired, the cookie wouldn't be sent due to the default 'lax' setting. Additionally, if non-simple requests like DELETE/PUT/PATCH are made, a preflight request would occur, blocking the malicious site's domain from the Access-Control-Allow-Origin header. Given these protections, can anyone provide examples where CSRF might still occur? Is there still a need for anti-forgery tokens today?
5 Answers
Verifying that a user is on a modern browser supporting SOP is good practice, but every major browser has supported it since the mid-90s, so this shouldn't be a major hurdle.
It's important to note that with the 'lax' setting, cookies can still be included in POST requests if the cookie was set within the last two minutes. So, CSRF attacks can still occur under certain conditions, even with measures in place.
I've found that many websites operate with separate backends and frontends across different domains, which makes it tricky. Using 'SameSite=strict' isn't always feasible, so sites often default to 'lax', which can leave a vulnerability for CSRF attacks if not properly managed. It's a real risk that needs to be addressed carefully.
Can you clarify what you mean by an attack point without CSRF? Is it just a different type of vulnerability that could be exploited?
While the SameSite attribute greatly helps reduce CSRF risks—especially with the 'strict' setting—there are still web apps that misuse GET requests with side effects. Furthermore, some might configure CORS poorly. In those cases, CSRF tokens can still provide an extra layer of security.
They'd do better by following good practices, ensuring their GET endpoints are indeed safe or idempotent, and avoiding wide-open CORS settings.
I still use CSRF tokens as an extra safeguard. Better to have multiple layers of security; they provide a good defense in depth against potential vulnerabilities.
Absolutely! Extra protection is always beneficial, especially when dealing with potential exploits.
If you're splitting your site across multiple domains, you might not be using cookies for sessions anyway. Checking for the Origin header on POST requests can help mitigate CSRF attacks by ensuring they come from expected sources.