另外來介紹一下CSRF（Cross-Site Request Forgery），這一種是把「受害者已登入的權限」拿來做壞事的攻擊方式。攻擊者誘導受害者在已登入的網站執行未授權的操作（像是轉帳、改密碼），而受害者根本沒注意到自己被利用。

攻擊流程（簡單示意）

1. 使用者 A 登入銀行網站並保有有效 session cookie。
2. A 同時開著另一個惡意網頁（攻擊者的頁面）。
3. 惡意頁面發出一個針對銀行的請求（例如：POST /transfer），瀏覽器會自動帶上 A 的 session cookie。
4. 銀行伺服器看到合法 cookie，就當成是 A 的操作並執行轉帳 -> 損失發生。

重點是：瀏覽器會自動帶 cookie，所以只要受害者已登入，攻擊就能利用這點。

常見防護措施（實務可用）

• CSRF Token（伺服器端產生）

  • 每個使用者 session 產生隨機 token，嵌入表單或回傳給前端，伺服器驗證請求中的 token 是否正確。
  • 最穩、最普遍的作法，適用於傳統表單與非同源請求。

• SameSite Cookie 屬性

  • 設 Set-Cookie: session=...; SameSite=Lax 或 Strict，可防止第三方網站發起跨站請求攜帶 cookie（Lax 對一般導航友好，Strict 最嚴格）。
  • 現在大多數瀏覽器支援，建議一併設定 Secure; HttpOnly。

• 檢查 Origin / Referer Header

  • 對於敏感操作（POST/PUT/DELETE），伺服器可檢查 Origin 或 Referer 是否來自自己信任的網域。
  • 注意：某些環境下 header 可能被隱藏或省略，不能完全取代 token 機制。

• 雙重提交 cookie（Double Submit Cookie）

  • 前端把 token 同時放在 cookie 與請求 body/header，伺服器比對兩者是否一致。實作上比單純檢查 header 更安全，但仍比不上 server-side token 綁 session。

• 避免把敏感操作設為 GET

  • GET 應該是安全且可重複的（idempotent），所有會改變伺服器狀態的操作請用 POST/PUT/DELETE 並搭配 CSRF 防護。

• 對 SPA 使用同源請求 + CORS + 授權 header

  • 單頁應用通常改用 token-based 認證（例如 Bearer token 存在 localStorage 或透過 Authorization header），並搭配 CORS 與檢查 Origin，減少 cookie 被濫用的風險。

開發者檢核清單（快速）

• [ ] 敏感表單/API 是否有 CSRF token 驗證？
• [ ] Session cookie 是否設定 SameSite、Secure、HttpOnly？
• [ ] 是否避免用 GET 做會改變狀態的操作？
• [ ] 是否對重要操作額外要求 re-authentication（再次輸入密碼）？
• [ ] 是否在測試環境用自動化掃描器（如 OWASP ZAP）檢查 CSRF 漏洞？

小結

CSRF 利用的是「瀏覽器自動帶 cookie」的行為；最可靠的防護還是 server-side 的 CSRF token + 正確 cookie 屬性設定。把敏感操作多一道驗證或雙重確認，就能大幅降低風險。