由于同源策略，CSRF 保护仅用于状态更改操作。该政策规定：

网络浏览器允许包含在第一个网页中的脚本访问第二个网页中的数据，但前提是两个网页具有相同的来源。

所以 CSRF 攻击将无法访问它请求的数据，因为它是一个跨站点（即CSRF中的CS）请求并且被同源策略禁止。所以非法数据访问不是 CSRF 的问题。

由于 CSRF 攻击可以执行命令但看不到其结果，因此被迫盲目行动。例如，CSRF 攻击可以告诉您的浏览器请求您的银行帐户余额，但它看不到该余额。这显然是一种毫无意义的攻击（除非你试图对银行服务器进行 DDoS 攻击或其他什么）。但是，例如，如果 CSRF 攻击告诉您的浏览器指示您的银行将资金从您的账户转移到攻击者的账户，这并不是没有意义的。攻击脚本无法访问传输的成功或失败页面。对攻击者来说幸运的是，他们不需要看到银行的回应，他们只想要他们账户里的钱。

由于只有状态变化的操作可能成为 CSRF 攻击的目标，因此只有它们需要 CSRF 防御。

通常安全的方法不必受到 CSRF 的保护，因为它们不会对应用程序进行更改，即使它们返回敏感信息，也会受到浏览器中的同源策略的保护。

如果您的站点是按照标准实施的，那么您的 GET 请求应该是安全的，因此不需要保护。

但是，在特定情况下可以执行“跨站点 DoS” ^*攻击。假设您的报告页面需要 10 秒来执行，您的数据库服务器上的 CPU 使用率为 100%，而您的 Web 服务器上的 CPU 使用率为 80%。

https://yoursite.example.org/Analysis/GetReport您网站的用户知道在办公时间永远不要去，因为它会杀死服务器并给其他用户带来糟糕的用户体验。

但是，Chuck想要让您的yoursite.example.org网站下线，因为他不喜欢您或您的公司。

在他经常发帖的繁忙论坛上http://forum.walkertexasranger.example.com，他将签名设置为：

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

他还知道贵公司的员工经常访问论坛，同时也经常登录yoursite.example.org。

每次您的员工阅读 Chuck 的一篇帖子时，身份验证 cookie 都会发送到https://yoursite.example.org/Analysis/GetReport，因此您的站点会处理请求并生成报告，并且您的系统会脱机，因为 CPU 被这些不断的请求占用。

因此，即使该请求是 GET 请求并且不会对您的系统进行任何永久性更改（也称为“安全”），它实际上每次运行时都会关闭您的系统。因此，最好使用 CSRF 预防方法来保护它。

^{*XSDoS，或跨站点拒绝服务，是我创造的一个短语，所以不要去谷歌搜索它。}

CSRF 保护不用于保护数据。它用于保护用户在不知情的情况下更改状态，例如转账或注销帐户。

因此，如果您的 GET 请求正在更改状态（不应该如此），那么您应该具有 CSRF 保护。但是如果它只是返回数据，它就不需要 CSRF 保护，因为在这种情况下 CSRF 保护不会保护任何东西。

再次浏览此页面可能会有所帮助：https ://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29

CSRF 或跨站点请求伪造不是保护数据不被检索，而是保护数据不被更改。这也称为状态更改。在应用程序中，状态更改可能包括个人资料数据，例如电子邮件地址、用户密码或个人简介，或转移资金。

GET 请求将用于幂等请求或不更改状态的请求。这些请求不需要具有反 CSRF 令牌。

POST 请求将用于非幂等请求或更改状态的请求。