顧客如何安全地更改帳戶電郵地址？

先認清地址控制哪些事情

帳戶電郵可能同時用作登入名稱、密碼復原、訂單收據及異常通知地址。修改它不等同更改一般聯絡資料。若攻擊者偷到仍有效的登入階段，便可能把地址改成自己的，再用新信箱重設密碼。真正的顧客也可能輸錯地址，或已無法打開舊信箱。OWASP 把更改電郵視為更改身份，建議重新驗證、通知原地址及確認新地址。實際步驟應視帳戶風險及是否已設多重驗證而定。

承諾即時生效前，先列出所有使用該地址的系統：登入、重設密碼、發票、送貨通知、客服紀錄及訂閱訊息，可能各有資料與同意設定。要分清帳戶識別地址和純粹收件偏好。內部應以穩定帳戶編號連繫資料，避免改地址後建立第二個顧客、分裂訂單歷史，或把另一人的紀錄錯誤合併。保存顧客原輸入的地址供顯示及通訊，同時訂明比較規則；OWASP 特別提醒，不應隨意套用某些郵件供應商的點號刪除等特殊轉換。

第一個決定是誰能發起變更。有效登入階段只是一個起點，不能單憑它批准敏感修改。應要求顧客再次使用既有驗證方式，例如已登記的多重驗證，或在只有密碼時重新輸入現有密碼。介面可解釋原因，但不要透露新地址是否已屬另一帳戶。如果顧客無法使用原有驗證方式，應走另有保障的帳戶復原流程；客服不能因為來電者說得出訂單號碼，就繞過驗證。

核實完成前保持待處理

收到表格後，先把新地址存為待處理，不要立即取代目前地址。向新信箱發出確認要求，使用與該帳戶及該次地址綁定、隨機、一次性、有時限的連結或代碼。原信箱收到變更通知，並有清晰方法回報並非本人提出的要求。OWASP 的身份驗證指引對只靠密碼的帳戶提出兩邊地址都確認的較嚴格流程；其電郵指引亦建議高風險系統考慮雙方確認。應按風險選定並記錄規則；「已寄出通知」不等於對方已閱讀。

顧客應能看到變更狀態。帳戶頁列明原地址仍有效、新地址等待確認，以及下一步要做甚麼。容許在合理限制內重寄確認訊息，也讓顧客取消自己誤發的要求。連結過期後，原地址應保持不變，並指示如何重新開始。若第二次要求取代第一次，必須使舊代碼失效，避免過時郵件日後突然改掉帳戶。當新地址已與另一帳戶關聯，亦須訂明處理方法，避免向未驗證的旁觀者洩露該地址是否已註冊。

確認成功是受控交接，不只是改資料庫欄位。在選定的核實條件都完成後，才更新有效地址，同步處理登入及復原對應，並確認之後的訂單訊息會寄到正確地方。按帳戶風險及登入設計，決定現有登入階段需否結束或重新驗證。再向舊地址發完成通知，讓顧客發現非本人操作。記錄要求和結果以便追查，但一般日誌不應保存確認代碼或包含代碼的完整網址。

上線前測試棘手情況

以一家小網店為例：顧客用電郵登入，另有幾張尚未完成的訂單，想由舊公司信箱改到私人信箱。測試先從現有登入階段開始，用既有因素重新核實；顯示待確認時，舊登入及訂單通知仍正常。新信箱確認後，才轉移有效登入及復原地址。團隊再用測試帳戶檢查訂單確認及密碼重設郵件的收件位置，不能拿真實顧客郵件做實驗。這驗證的是身份與通訊之間的關係，不只是畫面出現綠色成功提示。

再測失敗分支：新信箱收不到信、連結過期、顧客開兩個分頁，或第一次確認郵件在第二次要求後才到達，會怎樣？如果被盜登入階段提交攻擊者地址，而真正顧客按下舊信箱的警示連結，系統又如何處理？完成前要能取消及升級處理，客服亦要有凍結可疑要求的書面程序。無法使用舊信箱的顧客需要另一套復原判斷；在一般改址流程中悄悄跳過舊地址保障，規則便失去作用。

最後，通知文字必須與實際狀態一致。仍在等待確認時，不能寫「你的電郵已更改」。要說明確認信寄往哪個信箱、如何重試，以及在不洩露敏感資料下如何求助。英文與繁體中文都要清楚區分已提出、已確認、已過期、已取消及已完成。可觀察核實失敗、重複申請及異常取消作為覆核線索，同時限制日誌內的個人資料。可交付的標準是每個狀態都保住正確帳戶擁有人，並把收據和復原訊息送到已核實的目的地。

訂明例外情況的處理方法

電郵能否送達也是安全設計的一部分。確認信可能延遲、被拒收或落入垃圾郵件。介面可適度遮罩顯示目標信箱，提供受限制的重寄方法，並說明何時找客服。不能因寄送失敗就自動啟用新地址，因為控制權仍未獲證實。若舊地址的通知退信，應記錄為風險線索，按已訂例外流程處理。郵件服務商回覆「已接受」不代表收件人控制信箱，更不代表已閱讀。

待確認期間，各類業務訊息送去哪裏，應事先決定。新訂單收據可能仍須寄往目前已核實地址，直至新地址確認；帳戶頁要清楚說明。市場訊息的訂閱同意不應因登入地址變更便悄悄轉移或重設。若發票需重寄另一收件人，可能要由客服按另一套檢查處理。分開設計這些通訊路徑，可避免匆忙把一個欄位改動套到所有郵件，令顧客不知情。

客服需要範圍清楚、可測試的升級處理方法。職員可看要求狀態、時間及必要核實是否完成，但不應看到可重用的確認連結。顧客表示並非本人要求時，客服可暫停待處理變更並引導保護帳戶。若顧客已失去舊信箱，客服不能直接把它標記為已確認；獨立的復原政策須訂明替代證據及批准者。處理結果要記錄，個案存取亦要受限制。這些界線能保護緊張情況下的顧客與職員。

實作前可用一頁畫出狀態轉換：目前、待確認、已確認、已過期、已取消及有爭議。每條轉換都列出操作者、所需證明、發出的訊息，以及對登入和復原的影響。測試舊連結不能完成已被取代的要求、重用代碼會失敗、兩次同時確認不會造成互相矛盾的帳戶資料。最後按圖核對英文與繁體中文介面文案。簡單的狀態圖，能找出只看成功畫面時容易漏掉的問題，特別是登入、顧客資料及交易郵件由不同團隊管理時。

同一信箱亦可能由家庭或小公司多個人共用，而另一個系統卻假設每個地址只對應一個帳戶。上線前須訂明帳戶身份和重複地址的規則，不能只因信箱相同就暗中合併購買歷史。若擬用的新地址與既有紀錄衝突，應保留目前帳戶不變，給已登入顧客安全的客服處理路徑。同時測試提示訊息會否讓攻擊者探查其他帳戶是否存在。當電郵同時是登入名稱及收據目的地，錯誤合併尤其可能暴露訂單。客服處理時亦要核對實際帳戶，而不能把「能收到某封信」當作擁有所有相關訂單的充分證明。