CSRF 利用瀏覽器自動夾帶登入憑證送出跨站請求；防護應結合不可預測 Token、SameSite Cookie、Origin 驗證與無副作用的 GET。
攻擊利用的是瀏覽器的自動行為
使用者已登入某網站時，瀏覽器會依 Cookie 規則自動夾帶認證。惡意網站若能誘導瀏覽器向目標送出改密碼、轉帳、綁定帳號或刪除資料的請求，而目標只看 Cookie 就執行，便可能形成 CSRF。
攻擊者通常看不到回應內容，但不代表無法造成狀態變更。是否使用 HTTPS 與是否有 CORS 都不能單獨阻止一般表單型跨站請求。
使用者能做的有限但仍重要
不要在不需要時長期保持高權限後台登入；完成敏感操作後登出，並避免同一瀏覽器同時開啟來源不明的頁面。遇到突然要求重新驗證、授權或確認操作的頁面，應從官方入口重新檢查帳號活動。
真正可靠的防護必須由網站端完成，不能把責任推給使用者「不要點錯連結」。
每個狀態變更請求都驗證 Token
同步 Token 模式會把不可預測值放在伺服器工作階段與表單或自訂標頭中，兩者必須一致。Token 應綁定工作階段、使用密碼學安全亂數產生，且不出現在 URL。雙重提交 Cookie 也必須做完整簽章或綁定，不能只比較兩個可由攻擊者控制的值。
對 SPA 或 API，可把 Token 放在只有同源程式能設定的自訂標頭，並限制 CORS 來源與認證。不要接受萬用來源搭配認證。
Cookie 與來源驗證是額外層
工作階段 Cookie 優先採 SameSite=Lax 或 Strict；若業務必須跨站，將放寬範圍縮到專用 Cookie。伺服器也可驗證 Origin，必要時再參考 Referer，只接受明確允許的 HTTPS 來源。
來源標頭可能因隱私政策或舊客戶端缺失，因此要預先定義缺失時的策略，不能遇到問題就允許所有請求。Token 仍是主要控制。
GET 不得有副作用
搜尋、瀏覽與讀取可以使用 GET；改密碼、加入管理員、刪除、付款與寄信等操作應使用 POST、PUT、PATCH 或 DELETE，並驗證 CSRF。僅把 GET 改成 POST 仍不夠，因為跨站表單也能送 POST。
對高風險操作加入近期重新驗證、顯示明確確認內容與一次性交易識別碼，可以降低使用者在不知情下完成動作的可能。
如何驗證防護
建立測試確認：沒有 Token、Token 錯誤、其他工作階段 Token、跨來源 Origin 與舊 Token 都會被拒絕；正確同源流程則能成功。回應應使用 4xx，不要默默執行部分操作。
檢查所有入口，包括舊版 API、行動版、批次端點與管理後台。CSRF 漏洞常出現在主要表單已保護，但較少使用的 JSON 或上傳端點仍只依賴 Cookie。