Should I use CSRF protection for 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.

Ordinarily safe methods do not have to be protected against CSRF because they do not make changes to the application, and even if they're returning sensitive information this will be protected by the Same Origin Policy in the browser.

If your site is implemented as per standards, your GET requests should be safe and therefore do not need protection.

However, there is a specific case where a "Cross-Site DoS"^* attack could be executed. Say your reporting page takes 10 seconds to execute, with 100% CPU usage on your database server, and 80% CPU usage on your web server.

Users of your website know never to go to https://yoursite.example.org/Analysis/GetReport during office hours because it kills the server and gives other uses a bad user experience.

However, Chuck wants to knock your yoursite.example.org website offline because he doesn't like you or your company.

On the busy forum he posts to often, http://forum.walkertexasranger.example.com, he sets his signature to the following:

<img src="https://yoursite.example.org/Analysis/GetReport" width=0 height=0 />

He also know that your company employees frequent the forum, often while also logged into yoursite.example.org.

Every time one of Chuck's posts are read by your employees, authentication cookies are sent to https://yoursite.example.org/Analysis/GetReport, so your site processes the request and generates the report, and your system goes offline because CPU is eaten by these constant requests.

So even though the request is a GET request and doesn't make any permanent changes to your system (aka "safe"), it is infact bringing down your system every time it is ran. Therefore, it would be better to protect this with a CSRF prevention method.

^{*XSDoS, or Cross-Site Denial if Service, is a phrase coined by me, so don't go Googling for it.}

CSRF protection is not used to protect data. It is used to protect a user from unknowingly changing state, such as transferring money or logging out of an account.

Thus, if your GET request is changing a state (which it shouldn't be), then you should have CSRF protection. But if it's just returning data, it doesn't need CSRF protection, because CSRF protection wouldn't protect anything in this case.

It may help to go over this page again: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29