網站錯誤紀錄能協助維修，卻也可能把表單內容、登入憑證或客戶識別資料複製到主機與外部監測平台。本文用五項驗收問題，協助企業確認記錄目的、敏感欄位、存取、保存與刪除邊界。
客服收到客戶回報：「表單送不出去。」廠商為了除錯，打開主機或外部監測平台，看到整段送出內容、電子郵件、電話，甚至代表登入身分的存取權杖。問題修好後，這些副本可能仍留在日誌、告警信、工單與工程師下載的檔案裡。
系統日誌（log，也就是網站自動留下的事件紀錄）像店內的保全錄影。它應留下何時、哪個入口、發生什麼異常，幫助釐清責任；不代表每次事件都要把客戶交付的資料完整影印一份。記得太少，出事時查不到原因；記得太多，維修工具本身就會變成另一個需要保護的資料庫。
日誌是維修工具，也可能成為第二份客戶資料
網站發生錯誤時，系統可能記錄網址、裝置資訊、錯誤代碼、程式位置，以及請求內容。請求內容是瀏覽器送給網站的資料，可能包含表單欄位；存取權杖（access token）則像短期通行證，外洩後可能被拿來冒用登入狀態。
OWASP 的應用程式日誌指引建議，密碼、存取權杖、可連入資料庫的資訊、加密金鑰及敏感個資通常不應直接寫入日誌，應依用途移除、遮蔽、雜湊或加密。這不表示關掉所有紀錄。企業仍需要時間、事件類型、結果、錯誤代碼與互動識別碼，才能追查詢價失敗、權限異常與資安事件。
台灣《個人資料保護法》第 2 條把記錄、儲存、複製與內部傳送列入個人資料的處理；第 5 條要求處理不得逾越特定目的必要範圍；第 11 條也要求在目的消失或期限屆滿時，原則上刪除或停止處理、利用。日誌是否涉及個資，要看實際內容能否直接或間接識別個人，不能只因檔名叫「技術紀錄」就忽略。
用五個問題驗收「只是除錯紀錄」
- 為什麼要記？ 每一類事件要對應故障排查、安全調查或營運對帳目的。若廠商只能說「工具預設如此」，仍未說明必要性。
- 哪些欄位會進去？ 檢查網址參數、表單內容、瀏覽器附帶的技術資訊、錯誤訊息與畫面截圖，確認密碼、權杖、證件、付款資料及不必要的聯絡資訊已在寫入前排除或遮蔽。
- 資料送到哪裡、誰能看？ 除了主機，還要列出雲端監測、告警信箱、客服工單、聊天群組與下載檔，並確認內部、網站廠商及平台客服各自的權限。
- 保存多久、怎麼刪？ 正式日誌、匯出檔與備份要有期限、刪除方式及負責人。只清除平台畫面，不代表工單附件與個人裝置上的副本一起消失。
- 如何證明設定有效？ 用測試資料刻意觸發一個已知錯誤，逐站查看實際紀錄，再確認遮蔽後仍保留足以定位問題的時間、事件編號、狀態與原因。
明顯警訊包括：登入密碼或完整權杖可直接閱讀、每次錯誤都保存整份表單、廠商把原始日誌寄到私人信箱、任何維護者都能查看全部環境，以及沒有人知道平台的保存期限。
記得越多，不一定越容易修
最便宜的做法可能是沿用平台預設值，優點是上線快；缺點是欄位、權限與保存未必符合公司的資料流程。全面關閉詳細紀錄看似安全，卻可能讓間歇性故障、帳號濫用或交易爭議失去證據。合理取捨是先定義要回答的問題，再保留必要事件，把敏感內容在進入日誌前縮減。
遮蔽也有限制。只把畫面上的電子郵件塗黑，若原始值仍存在後端或匯出檔，風險沒有消失；用雜湊（把原值轉成固定代碼的方式）取代識別碼，雖能串起同一使用者的多次事件，仍要評估是否可能被重新對照。真正的驗收要看資料寫入、傳送、查看、匯出與到期的整條路徑。
今天先追一筆測試資料，不要先清空日誌
先挑一個高價值入口，例如詢價、登入或預約，用明確標示的假姓名、測試信箱與無效測試權杖走一次失敗流程。建立一張表，記下事件來源、實際欄位、接收平台、可讀角色、保存期限、遮蔽位置與刪除方式。不要用真實客戶資料，也不要直接刪除正式紀錄，以免破壞事故調查或合約要求。
如果發現敏感值，先限制查看與下載，再確認哪些副本已產生，之後才調整程式或平台設定。修正後重做同一測試，證明敏感欄位不再出現，同時保留足以追查的事件編號與錯誤原因。
自行處理的邊界與接洽準備
單一形象網站、沒有會員與敏感表單時，企業可先自行整理平台、廠商、查看人員與保存設定。若網站涉及會員、付款、求職、健康資料、多家外部服務，或已無法確認原始日誌被複製到哪些地方，就值得由技術、隱私與營運人員共同盤點，必要時再請法遵或法律專業判斷保存依據與事故處理。
接洽前可準備網站與表單清單、主機及監測平台名稱、合作廠商、最近錯誤工單、目前保存設定，以及一份已遮蔽的日誌範例。請不要傳送真實密碼、權杖或完整客戶資料。邊境部署可以協助把這些線索整理成資料路徑、遮蔽規則、權限與驗收測試；如果現況只需要一張人工清冊，也會先把範圍說清楚。