We migrated from a custom CSRF implementation to the one from Spring Security using the default CsrfFilter with HttpSessionCsrfTokenRepository.

The user opens a FTL/JSP-generated web page that contains a CSRFToken as hidden input field in a form. Then he is afk until the session timout hits. If he afterwards submits the form, issuing a POST request with a CSRFToken that is not known by the application server any more, the result is a AccessDeniedException with a 403 response.

Our previous implementation still let the request pass to the matching RequestMapping. There a handler-specific behaviour is implemented for the case that no session was found. Some handlers reload the page, some handlers redirect to a different page, and Spring Webflow restarts the current flow from the beginning.

If there is no session any more which could be hijacked, why does the Spring Security CsrfFilter reject the request?

Comment From: sjohnr

@rmueller83, thanks for getting in touch, but it feels like this is a question that would be better suited to Stack Overflow. We prefer to use GitHub issues only for bugs and enhancements. Feel free to update this issue with a link to the re-posted question (so that other people can find it) or add a minimal sample that reproduces this issue if you feel this is a genuine bug.

I will mention that this is addressed in the reference.

Comment From: rmueller83

This is not addressed in the reference. The reference only describes a generic handling, not a handler-specific.

Comment From: sjohnr

@rmueller83, feel free to open docs enhancement requests as a separate issue. Thanks.

Comment From: rmueller83

It seems a bit weird asking to add a buggy behavior (rejecting a safe request) to the docs...

Comment From: sjohnr

@rmueller83, thanks for sharing your thoughts. I'm sorry you feel this is a bug. However, as I triaged your request, I determined that it was not a bug, which is reinforced by the fact that this scenario is specifically documented and has been for some time. Additionally,

If there is no session any more which could be hijacked, why does the Spring Security CsrfFilter reject the request?

indicated you were asking a question which requires a broader discussion, hence I redirected you to stack overflow as we prefer to use GitHub Issues for only bugs and enhancements. Further,

This is not addressed in the reference. The reference only describes a generic handling, not a handler-specific.

indicated you were suggesting an enhancement to provide more examples for your scenario, which would normally be handled as an enhancement request. In that issue, we might discuss more about your use case to determine if the docs in fact should be updated or not.

Make sense?

Comment From: rmueller83

Hmm, I do not get the point. Rejecting the request is a bug. And enhancing the docs does not fix something the software handles incorrectly.

Comment From: eric-creekside

Hmm, I do not get the point. Rejecting the request is a bug. And enhancing the docs does not fix something the software handles incorrectly.

I agree. The fact that the end result is a 403, which in fact it should be either a 401 or an auto-redirect to login (depending on the app's Spring Security setup), is likely a bug. It doesn't matter that the docs talk about the situation, it's still an unexpected response and bordering on outright incorrect.