個人身份資訊 (PII) 應被視為敏感資訊，并且 OWASP 宣告敏感資料不應成為 URL 的一部分。https://owasp-aasvs.readthedocs.io/en/latest/requirement-9.1.html
GDPR 規定，直接或間接識別個人的“在線識別符號”是 PII。https://gdpr.eu/article-4-definitions/
提供用戶偏好的 API，其中資源項可能如下所示：
{
"id": "abc123" //generated id
"language": "en_EN",
"favoriteColor": "BLUE",
"userId": "[email protected]"
}
那么 API 可以鏈接到該資源嗎？
https://example.com/user-preferences/abc123
據我了解，這將是間接在線識別符號的一個示例。這是否意味著需要對 id 進行加密？如果是這種情況 - 這是否意味著 id 的每次加密（即每次從 API 提供 URL 時）都必須使用不同的鹽進行加密以避免引入新的間接識別符號？
同一資源的不同 URL：
https://example.com/user-preferences/87wytu09ufwc2ercler4ri // abc123 encrypted with salt A
https://example.com/user-preferences/diu4w98iuywfgommbvwdxe // abc123 encrypted with salt B
uj5u.com熱心網友回復：
我們在這里擁有的是對我們的 API 設計有直接影響的安全性和合規性要求。實際上，將敏感資料放入 URL 被認為是一種不好的做法（原因 - 每個代理、負載均衡器、API 網關、Web 服務器……在此程序中都允許記錄傳入請求的 URL 以用于除錯目的，我們不這樣做希望敏感資料以這種方式傳播）。另一方面——做 GET 請求最終會很棘手，因為我們不能把我們想要的所有東西都簡單地放入請求正文中。GET 請求的引數以 URL 結尾，因為 HTTP 和 REST 就是這樣設計的。
那么，我們可以做些什么來滿足安全性和合規性需求呢？我想到了至少兩件事。
- 將敏感資料放入請求標頭中。它們最終不會成為 URL 的一部分，因此問題解決了。
- 按照您的建議解決問題。這對這個行業來說并不是什么新鮮事。只需遵循解決不安全直接物件參考的路徑即可。
我自己會去1。在發生了什么以及如何處理測驗資料的情況下，它沒有 2 那么神秘。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/424286.html