As documented here, generating a csrf token with asp.net will also prevent the response to be cached by the browser.
Generates an AntiforgeryTokenSet for this request and stores the cookie token in the response. This operation also sets the "Cache-control" and "Pragma" headers to "no-cache" and the "X-Frame-Options" header to "SAMEORIGIN".
I initially assumed that this decision was made to prevent users from submitting a "stale" request token by using the browser "back" button. I later noticed that this might not be the reason, since :
- asp.net keeps the same cookie token for the whole session.
- asp.net allows the same request token to be submitted many times as long as the cookie token doesn’t change.
So, from my current understanding, using the browser back button and submit a cached html page should not be a problem ?
What is then the justification for disabling browser page caching when it contains a csrf token ? Is this a security best practice ?
As @serpent5 rightfully pointed out, the header
Cache-Control: no-store ensures that a public cache won’t cache the response and serve it to a different user. To clarify, I am more specifically interested in knowing if enabling browser caching (
Cache-Control: private) would have a negative impact on security.