Django的CSRF保護機制雖被廣泛應用，但在實際場景中存在以下關鍵局限性，需開發者特別注意：

---

一、內容類型限制（Content-Type約束）

1. 僅保護特定響應類型
   CSRF中間件默認只對text/html和application/xml+xhtml響應生效，對JSON/純文本API響應（如application/json）不注入Token。
   → 風險：若前端通過AJAX提交JSON數據但未手動添加CSRF Token，請求會被拒絕。

2. 解決方案

   // 前端手動添加Token到AJAX請求頭
   fetch("/api/", {method: "POST",headers: { "X-CSRFToken": getCookie("csrftoken"),  // 從Cookie讀取"Content-Type": "application/json"},body: JSON.stringify({ data: "test" })
   });
   

---

二、會話依賴性與Cookie機制局限

1. 強依賴Session Cookie
   CSRF驗證要求客戶端必須接受Cookie，且Token綁定到用戶會話。以下場景失效：

   • 瀏覽器禁用Cookie
   • 無狀態API服務（如JWT認證）
     → 矛盾：RESTful架構提倡無狀態，但CSRF機制需會話狀態。

2. Token與Cookie的綁定風險
   攻擊者若通過XSS竊取Cookie，可繞過CSRF保護（但此時XSS危害已遠超CSRF）。

---

三、客戶端安全假設的局限性

1. 無法防御客戶端惡意代碼
   若網站存在XSS漏洞，攻擊者可直接讀取DOM中的CSRF Token并構造請求，使防護完全失效。

2. 瀏覽器兼容性問題

   • 舊版瀏覽器（如IE<10）對SameSite Cookie支持不完善
   • 移動端WebView可能忽略Cookie策略
     → 需額外依賴Referer檢查，但Referer可能被篡改或缺失。

---

四、部署與配置陷阱

配置錯誤場景	后果	解決方案
中間件順序錯誤	Session未初始化導致Token失效	確保SessionMiddleware在CsrfViewMiddleware之前
全局禁用中間件	所有視圖失去保護	局部使用@csrf_protect裝飾器
未豁免安全HTTP方法	對GET請求誤校驗導致功能異常	僅校驗POST/PUT/DELETE

---

五、現代Web架構的適配挑戰

1. 微服務與跨域問題

   • 多子域名場景需配置CSRF_TRUSTED_ORIGINS
   • CORS預檢請求（OPTIONS）需豁免CSRF檢查。

2. 前后端分離架構
   SPA應用需手動實現Token傳遞邏輯，增加開發復雜度：

   # Django后端設置Cookie為HttpOnly（防XSS）但允許JS讀取
   response.set_cookie("csrftoken", token, httponly=False)
   

---

六、最佳實踐與規避方案

1. 補充防御層

   • 啟用SameSite=Strict Cookie屬性（防跨域攜帶）
   • 關鍵操作要求二次認證（如密碼確認）

2. 替代方案

   場景	推薦方案
   無狀態API	JWT + 自定義認證中間件
   高安全需求操作	驗證碼/二次授權
   避免Cookie依賴	使用Authorization頭傳遞Token