顧客下載發票時，如何避免看到別人的資料？

發票連結的真實教訓

發票不只顯示總額，還可能同時包含姓名、電話、電郵、送貨地址及購買資料。香港個人資料私隱專員公署曾公布個案：網店顧客把發票連結末尾五位數字改動，便能打開其他顧客的發票。店方在公署介入後修正問題，並收到警告。這給新發票功能一條明確驗收題：顧客改動網址、編號或請求後，能否取得別人的文件？原收件人順利開啟連結，只證明發送成功，並不能證明權限正確。

關鍵分別在於「知道文件位置」與「有權讀取文件」。發票編號可以連號、隨機，或使用很長的識別碼。OWASP 指出，各種形式的物件識別碼都可能被操弄；接收識別碼並操作物件的端點，須檢查該物件的授權。難猜的識別碼可減少隨手試探，卻不會讓持有編號本身等同獲准讀取。設計時應寫明每張發票可由哪個人或機構查看，以及下載當刻由哪個路徑執行權限檢查。

先畫出同一份發票可經哪些渠道離開系統：顧客帳戶頁、電郵連結、客服重發、手機應用程式、PDF 預覽、雲端儲存網址，或批次匯出。若帳戶頁有核對身份，預覽或附件端點卻直接派發檔案，整體權限仍然失效。OWASP 建議預設拒絕，並在每次請求時驗證權限。應按實際傳回的文件盤點路徑，不只看按鈕名稱；快取及儲存設定也要列入，因為受保護網頁背後可能藏著一條公開靜態檔案路徑。

先決定每張發票的可見範圍

個人購物可先採用簡單規則：與訂單相連、已登入的顧客帳戶可取回自己的發票。企業帳戶較複雜，採購人、財務聯絡人及公司管理員的權限可能不同；離職員工不應只因舊訂單留有其電郵便永遠可下載。開發端點前應把個案逐一寫明。發票連著訂單，訂單連著顧客或機構，當前請求人在這段關係中有某種角色。不可只憑表格輸入的電郵地址，或瀏覽器傳來的顧客編號推定擁有權。伺服器應從可信登入狀態取得請求人，再核對其與指定發票的現時關係。

訪客結帳需要另訂規則。公司可採用核實身份後領取、限制發送渠道，或其他經清楚界定的方法；不要悄悄把訂單號碼加電郵地址當作日後所有文件的通用密碼。還要考慮收件人轉寄訊息、多人共用郵箱，以及買家要求客服重發時會怎樣。短效下載連結可以有用，但有效期、適用對象及撤銷安排須配合文件敏感程度。系統應先核對請求人可否取得該張發票，才產生連結；連結會過期，本身不是擁有權核查。

客服需要獨立而可追查的途徑。員工或須查閱發票解答問題，但不代表每個員工帳戶都可瀏覽所有顧客的購物紀錄。應按角色列明存取理由和可做的動作：查看、重發、更正或匯出。重發時，按既有顧客紀錄及公司程序確認目的地，不應只憑未核實聊天訊息內的新電郵地址。記錄誰在何時處理哪張發票，方便事後調查；日誌本身不宜再複製完整發票或儲存多餘個人資料。

在派發文件時執行權限

穩健的下載流程應先找出所要求的發票，再判斷目前請求人與該一份文件是否具有獲准關係，通過後才讀取或傳送檔案。PDF 下載、瀏覽器預覽、縮圖、電郵連結兌換及 API 回應都應套用同一原則。路徑不可把瀏覽器送來的 customer_id 或 organisation_id 當成證明；它們只是輸入。亦要避免公開儲存空間或可長期直接使用的固定網址繞過應用程式。若由儲存服務發短效連結，發放前仍須經過同一授權判斷，並測試連結被轉寄或重用時是否超出原定範圍。

可用具體測試驗收：測試顧客甲有發票 2417，顧客乙有發票 2418。先確認甲按正常帳戶頁可取得 2417；再保持甲的登入狀態，改動網址或 API 參數嘗試取 2418。亦直接測試預覽及 PDF 路徑，不經帳戶頁。預期結果是乙的發票內容完全不會傳回，無論編號是連號還是亂碼。再用未登入瀏覽器及沒有該權限的員工帳戶重試。號碼純屬測試示例，並非真實外洩紀錄；測試截圖及回應亦應避免擴散真實顧客文件。

亦要測試合法邊界：有權的企業財務用戶應可取得其角色允許的發票；訪客要知道如何求助；訂單被轉移或退款後，顧客看到的狀態應正確。除了下載，也要檢查分頁及搜尋結果會否洩漏文件名稱或金額。拒絕存取時，以簡單訊息說明，避免透露別人的姓名或發票內容。可檢查日誌是否有人反覆改編號試探，必要時提示員工；偵測異常只能作輔助，不能取代伺服器端的擁有權核對。

上線後仍要守住同一規則

上線前，把每條權限規則整理成測試矩陣：請求人類型、發票擁有人、進入路徑及預期結果。每個路徑至少有一個允許及一個拒絕個案；如有員工角色或短效連結，也測試撤權、轉寄及過期情況。檢查內容派發網絡或瀏覽器快取會否在不再詢問應用程式的情況下傳回別人的文件。檔案儲存權限須與設計一致。使用虛構測試紀錄，讓團隊日後改程式仍可重跑，而不必不斷接觸真實顧客資料。測試矩陣應跟功能規格一起保存；單靠口頭說「開發者已檢查安全」很難重現。

若測試發現甲可打開乙的發票，應先停用或限制有問題的路徑，再查明哪些文件及渠道受影響、保留相關日誌、修正權限，並重測所有派發途徑才恢復服務。私隱專員公署公布的個案中，店方停止外部透過該連結存取，並改用另一種發送方式；那是個案結果，不代表所有商戶都必須電郵 PDF。自家系統應按實際資料、權限架構及事件事實決定補救。若已發生事故，應尋求合適的私隱及法律意見，不能假設修好程式便已處理所有責任。

若由外判團隊開發，老闆可要求現場示範兩個正常操作和一個拒絕操作：原顧客可下載；有權客服按批准流程重發；另一顧客改動請求後仍取不到同一檔案。示範須走真正的 PDF 或儲存端點，而不只是模型帳戶頁。這樣商業驗收有明確結果。好的顧客自助功能，應讓每份文件在派發時都有可解釋的權限判斷；交易量增加時，也不用靠犧牲私隱來換取方便。

系統搬遷或改版，也是尋找遺漏路徑的時機。舊發票可能沿用早期網址，新發票卻已走受保護端點。測試者應抽查兩代文件，看看已停用顧客帳戶、合併後的企業帳戶，或被撤銷權限的客服角色，能否取得舊檔。亦要檢查電郵存檔及搜尋索引中的檔名，會否直接指向公開物件。更換雲端供應商時，核對搬遷後儲存空間沒有意外變成公開。這是盤點與權限問題，不代表要刪除仍有正當會計或客服用途的紀錄。應訂明舊發票保存及領取途徑，讓失去原電郵的顧客仍有安全求助方式；否則員工可能自行分享直連，再次造成原本要消除的外洩風險。