-
Notifications
You must be signed in to change notification settings - Fork 73
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow CSRF token to be retrieved via the X-XSRF-TOKEN header #242
Comments
That's outside of the bundle's influence. It is using Symfony's CSRF token manager, specifically the Alternatively, you could inject your own implementation of |
Thanks for the reply :) I've realised my initial explanation wasn't clear enough. Let me clarify: |
Okay, I see what the problem is. To be honest, I totally forgot this was part of the implementation. Stupid question, how did you solve this for the initial login? Symfony's login mechanism should have the exact same challenge and I couldn't find anything how to make it read the csrf token from a header. |
For the initial login, I resolved the issue by creating a custom authenticator that extracts the token from the header and passes it to a CsrfTokenBadge. I wanted to implement the same approach for the TwoFactorAuthenticator. However, doing so requires removing the entire An alternative solution could be to force the JSON content-type instead, which would eliminate the need for CSRF protection if I am not mistaken, similar to how Symfony's JsonLoginAuthenticator operates. |
Did you find a way to solve this? Given the current implementation, the only way I can think of would be to replace either |
Description
I am integrating a 2FA flow within a Single Page Application (SPA) and have implemented an endpoint (GET /set_csrf_cookie) similar to Laravel Sanctum. This endpoint sets a CSRF-TOKEN cookie (httpOnly: false + SameSite: LAX) for the current session. Consequently, libraries like Axios and other JS XHR tools automatically include the CSRF token in the X-XSRF-TOKEN header of every request.
While it might initially seem unsafe to store a CSRF token in a cookie, this approach is secure due to the SameSite policy combined with CORS. Since a custom header is used and the content type is application/json, the request is not classified as "simple," mitigating potential risks. Although it is also possible to send the CSRF token within the JSON payload, I think we all prefer a single source of truth, rather than varying the method based on endpoints.
It would be very nice if some extension point or configuration option was being added to specify that the CSRF token should be extracted from the request header. Adding such an extension point or configuration option would significantly simplify this process. If this feature request is approved I can create a PR :)
The text was updated successfully, but these errors were encountered: