The attack vector here is disclosure of the token. The defense is not so much concerned with specifically how that token is disclosed, but addresses any method in which an attacker might obtain that value. If an attacker can obtain the token, that opens the possibility they can craft a CSRF attack. Again, the specific method of attack itself isn't the concern here.
The purpose of changing the token is to limit the window of opportunity. You could have the CSRF token change once a month or have it change on every request. Changing it with every session is a good middle ground that avoids some of the complications of a token changing too fast yet still provides good limits of exposure. Ending a session is also a natural transition of state, so that also makes it a good place to change the CSRF token.
Limiting your overall exposure to CSRF can make changing the CSRF token with every session less important. Some ways to do that are:
- Passing the token as HTTP header rather than a form value.
- Properly using POST vs GET requests when updating data or initiating transactions.
- Using the SameSite cookie attribute, the Secure attribute, and the __Host- or __Secure- cookie prefixes to help protect cookies from exposing information or being overwritten.
- Using the Origin and Referer HTTP headers to verify that the request came from the expected location.
- Providing additional interactive steps such as a confirmation page or even re-authentication for the most sensitive actions.
Deciding when to renew the CSRF token depends on your overall risk and general resistance to CSRF attacks. With a good defense-in-depth strategy you might be able to compromise on on how frequently you change that token.