防止偽造瀏覽器請求更改顧客帳戶

先找出會改動帳戶的請求

跨站請求偽造是瀏覽器信任問題：另一網站誘使瀏覽器向商戶網站發送請求，而瀏覽器可能自動附上顧客的登入 Cookie。即使系統知道登入者是誰，顧客仍未必同意該次變更。攻擊者不一定要讀到回應，部分改動已可發生。先列出修改送貨地址、加入復原方式、更新個人資料或移除已儲存資料等操作。更改電郵通常還要額外核實，但發出最初申請的步驟仍須防止非自願請求。應區分「顯示頁面」與「改寫紀錄」。登入驗證回答瀏覽器代表誰；CSRF 防護則判斷這次請求是否經由預期途徑發出。

盤點真實路由、HTTP 方法與使用端，不要只看可見的帳戶頁面。舊表格端點、AJAX 請求、手機內嵌網頁及後台捷徑，可能都會觸發同一業務操作。逐一記下使用瀏覽器 Cookie、Bearer 憑證還是其他認證方式，因為瀏覽器自動夾帶 Cookie 是此風險的核心。確認 GET 等安全方法不會改動紀錄。若按一條連結就能透過 GET 刪除地址或確認偏好，外部網站便容易誘發；SameSite=Lax 在頂層安全方法導覽時仍可能送出 Cookie。若現有流程用 GET 改資料，應先重設操作，不能把 Cookie 屬性當作唯一修補。

按請求途徑選擇主要防線

伺服器產生的表格，通常可先採用框架已驗證的 CSRF 防護，而不是自行設計權杖。OWASP 說明同步權杖可按登入時段或單次請求產生，由應用程式頁面交給瀏覽器，再經隱藏表格欄位或應用程式請求標頭送回。伺服器須在改動資料前，把收到的值與時段中的預期值比較；缺少或不符便拒絕。權杖不可放在網址或日誌。每次請求更新權杖可縮短重用時間，但返回舊表格再提交時可能受阻，故須預先設計復原方式。登入時段權杖較易使用，仍必須保密、不可預測，並於時段轉換時更新。

JavaScript 客戶端可採用自訂請求標頭作主要防線，但伺服器必須嚴格要求該標頭，並只容許可信來源送出帶憑證的跨來源請求。OWASP 解釋，自訂標頭會觸發瀏覽器的 CORS 預檢；若把大量子網域或帶憑證的來源放行，這道邊界便會失效。平日客戶端送 JSON，不代表端點自然安全；要確認伺服器拒絕可直接跨站送出的簡單內容類型，以及所有缺少預期標頭仍可改資料的旁路。若必須使用無狀態雙重提交模式，應依 OWASP 使用與登入時段綁定的簽署版本，避免只比較 Cookie 與參數是否相同。選定方案後，每條寫入路徑都要核實。

以 Cookie 及來源核對加強邊界

登入 Cookie 應明確設定符合實際流程的 SameSite 政策，然後測試外部連結、登入後返回及內嵌環境。MDN 和 OWASP 均指出，SameSite 可減少部分跨站 Cookie 傳送，但對多數部署而言並非完整的 CSRF 防護。Lax 可容許顧客從外部連結進站；Strict 可能令這類導覽中的登入狀態中斷；None 容許跨站情境，並須配合 Secure。另要記住「同站」範圍比「同來源」廣：兄弟子網域可以是不同來源，卻仍屬同站。若有較低信任度的託管內容或沿用的子網域，也要納入風險審視。Cookie 設定應按真實入站路徑決定，而非認定單一值適用所有網站。

伺服器亦可把請求的 Origin 與預先設定的目標來源比較，只有按明確政策才改用 Referer。OWASP 提醒，系統位於代理伺服器後方時，應用程式所見主機名稱可能與公開網址不同；只有已設定、並會覆寫用戶自帶轉送標頭的可信代理，才可提供可信主機資料。缺少標頭或 Origin: null，不能當成安全證明。應決定當合法請求沒有可用來源標頭時，是否改由有效權杖作後備；若受保護寫入沒有通過任何核准檢查，就要拒絕。Fetch Metadata 標頭可為現代瀏覽器提供另一訊號，但支援情況和例外仍須測試。

讓拒絕結果安全且可理解

顧客把帳戶表格開了很久、按返回鍵，或在另一分頁重新登入後，可能遇到失效的權杖。應把這次操作視為已拒絕，而非部分改動已生效。清楚說明資料尚未更改，並提供重新載入表格的方法；在安全可行的情況下保留非敏感輸入。錯誤頁面不應回顯權杖、原始保安規則或私人帳戶值。伺服器日誌可記錄足夠的拒絕情境供排查，但不要寫入權杖。通過 CSRF 核對後仍須檢查授權：某帳戶的有效權杖，不會授權修改另一帳戶紀錄。高影響操作或需再次確認或另行通知，但這些措施處理其他風險，不能取代 CSRF 防護。

以地址簿更改作示例：已登入顧客打開地址頁面，取得伺服器認可的表格，然後提交新送貨地址。只有登入時段、CSRF 及紀錄歸屬檢查均通過，才可寫入。第二個測試由外部頁面在顧客仍登入時，嘗試用瀏覽器表格觸發同一端點；請求因缺少有效權杖或未通過核准的跨來源條件而被拒，地址不變。第三個測試讓顧客重新登入後返回舊表格；系統拒絕過期提交、保留原地址，並引導取得新表格。三種結果都應對照資料庫及顧客確認畫面，不可只憑 HTTP 回應字樣推斷成功。

改動後覆核每條入口

由端點清單建立測試矩陣：有效、缺少、被改動及過期權杖；外來 Origin；沒有來源標頭；安全方法導覽；以及每項獲允許的跨來源整合。對每次受保護寫入，同時核對回應與資料庫是否真的依預期改動或維持不變。新增子網域、代理、內嵌結帳或升級框架後要重試，因為它們可改變來源判斷或暴露以前遺漏的路徑。監察拒絕情況並保留足夠脈絡，以找出被誤擋的正常流程；不能因某瀏覽器缺少標頭便直接放寬規則。每條路由都應有記錄好的判斷，包括可接受的後備方式及有權批准例外的負責人。

客服回報可反映流程阻滯，卻不能單憑數量證明有人攻擊，也不能證明系統安全。推出更新後若權杖失敗突然增多，可能是快取了舊表格、Cookie 範圍錯誤、代理設定改動，亦可能是惡意活動；必須調查分辨。帳戶表格快取策略要配合權杖生命週期，復原方法須讓顧客找到，不應要求盲目重做敏感變更。只有真正取得量度資料時才討論成效。業務上要確定的是：每項帳戶改動都設有可靠的授權與意圖邊界，在實際瀏覽器流程及失敗情況下同樣有效。

應記錄應用程式在哪一刻正式提交變更。若瀏覽器請求會啟動非同步工作，必須在工作進入佇列前保護起始請求；之後的處理程式無法重新判斷瀏覽器操作是否出於顧客意願。同一按鈕若觸發多個服務呼叫，每個可由外部到達、會改動狀態的入口都要有政策。審查時請開發人員展示中介程式執行次序，並以無效權杖測試資料庫和工作佇列均沒有變動。這比只看到表格中有一個權杖欄位更有意義。成功時亦應向顧客確認完成了哪項操作，避免被拒與成功看起來一樣。