session management – Do I still need a CSRF token?

When a client makes the first request, I send a session ID cookie generated by the server as a string of 64 random bytes using getrandom(2) or /dev/urandom, stored in the database, with the flags HttpOnly, Secure and SameSite=Strict set. Additionally, the server sends a Content-Security-Policy header with the value default-src 'none'; script-src 'self'; connect-src 'self'; style-src 'self'; img-src 'self', base-uri 'self'; form-action 'self'; frame-ancestors 'none', and it doesn’t send any Access-Control-Allow-Origin header. I have no subdomains, all state changing requests are POST requests, and all data is properly escaped, which makes XSS impossible.

If a client makes a request in the future, I check if the request contains a session ID cookie and if that session ID is in the database, otherwise I ignore the session ID they send and create a new one as described above.

In this scenario, what advantages would a CSRF token provide, if I want to protect against someone impersonating someone else?

I can’t think of any way in which an attacker would be able to send a request that the server would think belongs to another user. In order to do that, they’d need the user’s session ID, and I can’t see how they could obtain it, unless the user uses an old browser which doesn’t understand the cookie flags or the Content-Security-Policy header, but I can protect against that by requiring the user to use a browser version known to support both.

If the CSRF token indeed doesn’t provide any extra layer of security for the purposes of defending against impersonation, is there any other benefit of using a CSRF token in this scenario?