Hi,

I'm still not entirely sure if it's a bug or a configuration error (but in that case, I couldn't find how to fix it in the docs).

There's an unanswered StackOverflow question about this very same issue : https://stackoverflow.com/questions/54431454/spring-boot-security-adding-2-xsrf-token-in-response-header-cookies

I see in the response header, 2 set-cookie for XSRF-TOKEN as below. Not sure why. set-cookie: XSRF-TOKEN=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/hidden set-cookie: XSRF-TOKEN=5564cfc1-884d-4b89-9bb9-11a92f42bcc7; Path=/hidden

I experience the same issue with Kotlin DSL (StackOverflow's is another user, that went with Java Conf)

        // Config CSRF
        csrf {
            csrfTokenRepository = CookieCsrfTokenRepository.withHttpOnlyFalse()
        }

It seems harmless / properly handled by the clients I use, but it doesn't seem to be RFC compliant, and it might cause some issues with some proxies seeing that some were tempted to handle headers in hashmaps (fixed bug in envoy https://github.com/envoyproxy/envoy/issues/7488 but it doesn't mean they handle multiple set-cookies with same name without issues).

https://datatracker.ietf.org/doc/html/rfc6265#section-4.1.1

Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name. (See Section 5.2 for how user agents handle this case.)

Any idea if this is a conf error on my end (and if so, it could be very nice if the StackOverflow question could receive some pointers), or a Spring Security bug ?

Regards,

François

Comment From: sjohnr

Hi @fcabouat, thanks for reaching out and welcome to the project!

I believe this is expected to some degree, as it seems to be a consequence of CsrfAuthenticationStrategy:

https://github.com/spring-projects/spring-security/blob/9a57b42786accb4d806288f589c2750ca43de563/web/src/main/java/org/springframework/security/web/csrf/CsrfAuthenticationStrategy.java#L57-L59

If I'm correct that this is where the behavior you mention stems from, note that it has been this way since at least 2013 when the support was added. Perhaps @rwinch can shed some light on the reason(s) behind saving a null/empty token prior to saving a newly generated token.

Comment From: rwinch

This happens if the token is deleted and then a new one is created to replace it to prevent a form of session fixation attack. Are you having a concrete problem with things working or do you just find the duplicate header confusing?

Comment From: fcabouat

Hi, It's the latter : it doesn't create particular issues, but is confusing and doesn't seem to be RFC compliant. Not a high priority bug though.

Comment From: rwinch

Thank you for the follow up. I don't think this is an issue with Spring Security because Spring Security manages the cookie through the Servlet API and thus the servlet container should handle this if it is a problem since any Cookie could have this problem.

Given the above, I'm going to close this issue. If you disagree, please explain why this should be handled by Spring Security rather than the servlet container.

Comment From: tnobody

Hi,

we just stumbled upon this behaviour. I our scenario a reverse-proxy seems to process the (resp.-) headers and for some reason changes the order of the set-cookie header. After this the already expired cookie is set and due to the expired-date directly discarded. I know this not directly an issue for spring-security. I just wanted to point out that there can be such a case.

Br