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:
Therefore, if a website has kept to the standard and only implements "unsafe" actions as POSTs, then here only POST requests are vulnerable.
- 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