有多种减轻威胁的技巧：
[1] 策略：库或框架
使用不允许此弱点出现的经过审核的库或框架，或提供更容易避免此弱点的构造。
例如，使用能防御 CSRF 的软件包，例如 OWASP CSRFGuard -
http://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet另一个示例为“ESAPI 会话管理”控件，其中包括针对 CSRF 的组件 -
http://www.owasp.org/index.php/ESAPI[2] 确保应用程序中没有跨站点脚本编制问题 (CWE-79)，因为通过使用攻击者控制的脚本可绕过大部分 CSRF 防御。
[3] 为每个表单生成唯一的现时标志，将现时标志放到表单中，并在接收表单时验证现时标志。请确保现时标志是不可预测的 (CWE-330) -
http://www.cgisecurity.com/articles/csrf-faq.shtml请注意，通过使用 XSS (CWE-79) 可绕过这一点。
[4] 识别特别危险的操作。在用户执行危险操作时，发送单独的确认请求以确保是用户自己希望执行该操作。请注意，通过使用 XSS (CWE-79) 可绕过这一点。
[5] 使用“两次提交的 cookie”方法，如 Felten 和 Zeller 所述：
在用户访问站点时，该站点应生成伪随机值，并将其设置为用户机器上的 cookie。站点应要求每次表单提交都包括该值作为表单和 cookie 值。向站点发送 POST 请求时，只有表单和 cookie 值相同时才应将该请求视为有效。
由于同源策略，攻击者无法读取或修改 cookie 中存储的值。要以用户的身份成功提交表单，攻击者必须正确猜出伪随机值。如果伪随机值的保密性很强，这将是极端困难的。此技巧需要 JavaScript，因此对于禁用了 JavaScript 的浏览器可能无效 -
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.147.1445请注意，使用 XSS (CWE-79) 有可能绕过这一点，或者在使用支持攻击者从 HTTP 请求中读取原始头的 Web 技术时也有可能绕过这一点。
[6] 请勿对触发状态更改的任何请求使用 GET 方法。
[7] 检查 HTTP Referer 头以查看请求是否源自预期的页面。这可能会破坏合法功能，因为用户或代理可能已出于隐私原因而禁止发送 Referer。请注意，通过使用 XSS (CWE-79) 可绕过这一点。
攻击者可能使用 XSS 来生成欺骗性的 Referer，或从允许使用其 Referer 的页面生成恶意请求。
