CSRF Token in GET request

If you're generating the tokens in a secure random fashion, then an attacker cannot infer the next token from the previous ones. So there shouldn't be any realistic risk.

Another important point here is to use SSL. Any proxies/reverse proxies between the user and the server cannot even see the GET parameters to log them. The only places where the token is logged is on the two ends of the SSL connection.

Logging on the user's end (History, for example) happens after the link is clicked. Logging on the server's end carries no risk (if you don't trust the place where the SSL traffic is decrypted, then there are bigger problems).

GET requests should be idempotent, which means you can't invalidate the token once used because any repeat requests won't give the same response.

GET requests should also never make state changes to the system, therefore should not be required to have CSRF protection. Even logout should not be a GET request for the method that actually executes the logout (although you could have a GET link that navigates to another page before a POST request carries out the action).

To fix the idempotent problem, with a repeated GET request and with the same CSRF token supplied, you could display the cached response from the first request, without making any state change. However, you're still violating the standard if you make state changes at all, see rfc7231:

Request methods are considered "safe" if their defined semantics are
essentially read-only

Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe.

As a side note, I would also argue that resource intensive processes should also be POSTs (with CSRF protection) rather than GETs, otherwise an attacker could DoS a system using a CSRF vector.

Therefore, if you need CSRF for a method, then don't implement this as a GET.

Considering that by the time someone logs the token, it will already be invalidated and unusable should the attacker want to perform CSRF.

There is a corner case if the user gets the address but fails to actually use the token (due to transient network failures etc). It's unlikely this is significant enough to worry about for a CSRF token, but can be a problem for other more sensitive tokens.

Single-use CSRF tokens tend to pose usability problems, though, such as breaking navigation and multi-tab browsing... not to mention they're super-ugly. :-) Given that GET requests should be idempotent and thus not in need of CSRF protection, token-in-URL is usually a design smell. But I doubt there's much you can exploit here.