在設計 API 時，一個常見的錯誤是為了開發方便，將後端的資料庫物件模型 (Entity) 直接序列化後，完整地傳送給前端。這種做法雖然省事，但常常會導致「敏感資料曝露 (Sensitive Data Exposure)」漏洞，即 API 的回應中包含了前端根本不需要、但卻高度敏感的資訊。
什麼是敏感資料曝露？
此漏洞指的是，應用程式的 API 回應或系統日誌、錯誤訊息中，包含了不應被使用者或外部系統得知的敏感資訊。即使這些資料沒有被直接顯示在使用者介面上，但任何能夠攔截或查看網路流量的攻擊者，都可以輕易地從 API 回應中發現這些被洩漏的資料。
攻擊原理與範例
情境：約會 App 洩漏了你的位置
- 不安全的 API 設計：一個約會 App 在顯示附近使用者列表時，其後端 API
/api/users/nearby回傳了一個 JSON 陣列。為了方便，開發者直接將資料庫中的User物件完整地回傳，其中包含了使用者的姓名、照片、簡介，以及精確的經緯度座標。 - 前端正常顯示：App 的前端介面只顯示了使用者的照片和暱稱，並未顯示地理座標。從表面上看，一切正常。
- 攻擊者攔截流量：然而，一個具有技術背景的惡意使用者，使用中間人代理工具（如 Burp Suite）攔截了 App 的網路請求。
- 發現洩漏的資料：他查看了
/api/users/nearby的 API 回應內容，驚訝地發現每個使用者的精確 GPS 座標都被包含在 JSON 資料中。 - 攻擊成功：攻擊者可以利用這些洩漏的座標，精確地追蹤任何一位 App 使用者的即時位置，造成嚴重的人身安全威脅。
風險與影響
- 使用者隱私受損：洩漏個人身份資訊 (PII)、地理位置、聯絡方式、財務狀況等。
- 商業邏輯與數據外洩：API 回應中可能包含內部的利潤、成本、庫存等商業秘密。
- 提供攻擊線索：洩漏的資料（如檔案系統路徑、內部 IP 位址、資料庫結構）可以幫助攻擊者更深入地攻擊系統。
- 違反隱私法規：觸犯 GDPR、PCI-DSS 等法規，面臨罰款。
防禦與預防措施
核心原則：只傳送前端真正需要的資料，一分不多，一分不少。
1. 使用資料傳輸物件 (Data Transfer Objects, DTO)
- 這是防禦此漏洞的最佳實踐。不要直接回傳資料庫的 Entity 物件。
- 應針對每個 API 端點的需求，建立一個專門的 DTO。在後端邏輯中，手動將 Entity 中的必要欄位，複製到 DTO 中，然後只回傳這個 DTO。這樣可以確保只有白名單內的欄位會被傳送出去。
2. 進行資料分類與盤點
- 了解你的應用程式正在處理哪些資料，並根據其敏感度進行分類。
- 對所有 API 進行審查，確保它們回傳的資料符合最小權限原則。
3. 統一處理錯誤訊息
- 設定全域的錯誤處理機制，確保詳細的系統錯誤（如堆疊追蹤、資料庫錯誤訊息）不會直接顯示給使用者。應回傳通用的、不包含敏感資訊的錯誤代碼或訊息。
4. 加密敏感資料
- 對於必須傳輸的敏感資料，除了使用 HTTPS 外，還可以考慮進行應用層級的加密，確保只有客戶端能解密。
說些什麼吧！