I've seen several blanket statements on the web to the effect that you don't need CSRF protection for GET requests.

But many web applications have GET requests that return sensitive data, right? Then wouldn't you want to protect those against CSRF attacks?

Am I missing something, or are these blanket statements  assuming that the data the GET request gives is unimportant?

Examples of blanket recommendations gainst using CSRF tokens with GET:


https://security.stackexchange.com/a/90027/5997


  Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are vulnerable. 

http://www.django-rest-framework.org/topics/ajax-csrf-cors/


  
  Ensure that the 'safe' HTTP operations, such as GET, HEAD and OPTIONS cannot be used to alter any server-side state.
  


The assumption here is that if GET doesn't modify state, it's not worth protecting.
http://sakurity.com/blog/2015/03/04/hybrid_api_auth.html contains a code line that suggests this approach:

# 1) verify CSRF token for all non-GET requests



CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:


  a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.


So the CSRF attack will not be able to access the data it requests because it is a cross-site (that's the CS in CSRF) request and prohibited by the same-origin policy. So illicit data access is not a problem with CSRF. 

As a CSRF attack can execute commands but can't see their results, it is forced to act blindly. For example, a CSRF attack can tell your browser to request your bank account balance, but it can't see that balance. This is obviously a pointless attack (unless you're trying to DDoS the bank server or something). But it is not pointless if, for example, the CSRF attack tells your browser to instruct your bank to transfer money from your account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Fortunately for the attacker, they don't need to see the bank's response, they just want the money in their account. 

As only state-changing operations are likely to be targets of CSRF attacks, only they need CSRF defenses. 
