CSRF 攻擊可以使用以下方法來防護：

　　進行同源檢測，服務器根據 http 請求頭中 origin 或者 referer 信息來判斷請求是否為允許訪問的站點，從而對請求進行過濾。當 origin 或者 referer 信息都不存在的時候，直接阻止請求。這種方式的缺點是有些情況下 referer 可以被偽造，同時還會把搜索引擎的鏈接也給屏蔽了。所以一般網站會允許搜索引擎的頁面請求，但是相應的頁面請求這種請求方式也可能被攻擊者給利用。(Referer 字段會告訴服務器該網頁是從哪個頁面鏈接過來的)

　　使用 CSRF Token 進行驗證，服務器向用戶返回一個隨機數 Token ，當網站再次發起請求時，在請求參數中加入服務器端返回的 token ，然后服務器對這個 token 進行驗證。這種方法解決了使用 cookie 單一驗證方式時，可能會被冒用的問題，但是這種方法存在一個缺點就是，我們需要給網站中的所有請求都添加上這個 token，操作比較繁瑣。還有一個問題是一般不會只有一臺網站服務器，如果請求經過負載平衡轉移到了其他的服務器，但是這個服務器的 session 中沒有保留這個 token 的話，就沒有辦法驗證了。這種情況可以通過改變 token 的構建方式來解決。

　　對 Cookie 進行雙重驗證，服務器在用戶訪問網站頁面時，向請求域名注入一個Cookie，內容為隨機字符串，然后當用戶再次向服務器發送請求的時候，從 cookie 中取出這個字符串，添加到 URL 參數中，然后服務器通過對 cookie 中的數據和參數中的數據進行比較，來進行驗證。使用這種方式是利用了攻擊者只能利用 cookie，但是不能訪問獲取 cookie 的特點。并且這種方法比 CSRF Token 的方法更加方便，并且不涉及到分布式訪問的問題。這種方法的缺點是如果網站存在 XSS 漏洞的，那么這種方式會失效。同時這種方式不能做到子域名的隔離。

　　在設置 cookie 屬性的時候設置 Samesite ，限制 cookie 不能作為被第三方使用，從而可以避免被攻擊者利用。Samesite 一共有兩種模式，一種是嚴格模式，在嚴格模式下 cookie 在任何情況下都不可能作為第三方 Cookie 使用，在寬松模式下，cookie 可以被請求是 GET 請求，且會發生頁面跳轉的請求所使用。