開發者工具 · UUID 產生器
順序 ID 洩漏業務資料：為什麼公共 API 會暴露 UUID
· 為什麼它很重要
uuid 密碼學 瀏覽器 API
自動遞增 ID 告訴外部人員您接受了多少訂單，並使每筆記錄都可列舉。這篇文章解釋了公開 UUID 可以修復什麼、不能修復什麼，以及如何在不遷移的情況下引入它們。
您的發票號碼告訴競爭對手您的數量 - /orders/10482 中的資訊洩露
傳回 /orders/10482 的 API 端點告訴外部人員的資訊不僅僅是訂單詳細資訊本身。數字標識符表示您已經處理了至少一萬個訂單，暗示了有關您的成長率的信息，並使每個訂單都可以猜測。透過序號進行簡單循環即可檢索所有記錄，無需進行身份驗證或權限檢查。這種模式隨處可見——URL、資料庫金鑰、發票號碼和交易 ID——即使系統需要身份驗證才能查看任何單一記錄。問題在報告和分析中變得更加複雜。可以取得 /orders/1, /orders/2, 並繼續存取 /orders/10482 的攻擊者可以全面了解您的訂單歷史記錄和趨勢。
枚舉與抓取 — 順序 ID 如何將一筆公開記錄轉換為所有記錄
順序模式揭示了訂單到達時間、提及哪些產品以及定價模式的趨勢。觀察者了解您的業務成長或收縮的速度。這些僅從 ID 枚舉中得出的信息可以為競爭策略提供信息，指導社會工程或為其他攻擊提供時間信息。這種暴露不需要任何成本就能發現，並會出現在 URL、瀏覽器歷史記錄、快取頁面和伺服器日誌中。這不是理論上的：競爭情報公司和好奇的工程師通常會從公開可枚舉的 ID 中提取業務指標。訂單號樣本向任何有足夠積極性收集資料和執行基本分析的人揭示了生產力和總量。
一段中的德國坦克問題 — 根據連續數字樣本估計總數
枚舉應用統計分析來估計總量並追蹤時間模式。如果第一個訂單發生在已知日期，並您捕獲了一周內 10 個訂單的證據，則平均間隔可估算總體比率。競爭對手、投資者和攻擊者無需存取 ID 本身以外的任何客戶資料即可獲得您的速度。順序標識符保證每個大於當前數字的 ID 都可以預測未來的訂單；每個低於樣本中最小值的 ID 都證實您先前的操作較小。歷史資料點創建成長時間表並實現預測。同樣的原則也適用於各行業：金融交易、貨運訂單、醫療記錄以及任何公開序列 ID 的系統。
UUID 解決的問題 — 不可猜測的引用以及 ID 本身沒有成長訊號
當從 RFC 9562 為版本 4 指定的加密安全來源產生時，隨機產生的 UUID 包含 122 位元熵。此標識符不可猜測，不可枚舉，並不會向外部觀察者透露任何有關增長率或數量的信息。知道 /orders/9a1f4e2b-7c3e-4d1a-8a5f-1b2c3d4e5f60 的攻擊者無法預測下一個訂單的 UUID 或以任何合理的信心向後遍歷您的歷史 ID。 UUID 本身變成唯一但完全不透明的引用。隨機分佈意味著多個查詢不會向監控您的 API 的外部觀察者揭示任何模式、沒有進展、也沒有速度資訊。
UUID 無法解決的問題 — 不可猜測的 ID 不是授權，模糊性背後仍然需要存取檢查
在公共 API 中以 UUID 取代順序 ID 操作起來很簡單，且不需要係統之間進行複雜的協調。將 UUID 欄位新增至訂單表中，為每個新訂單產生一個資料列，在回應中公開 UUID 並逐漸棄用數字鍵。您的內部系統可以繼續使用整數主鍵以提高效能和簡單性；僅公共介面發生變化。舊的順序 ID 保留在資料庫中供您自己參考或審計跟踪，但客戶和第三方只能看到 UUID。這種雙密鑰方法是維護現有索引效能同時向外界公開不透明識別碼的最佳實務。
工作範例 - 在內部整數鍵旁邊新增公用 UUID 欄位並僅公開前者
此方法與實際授權不同，因為 UUID 不是密碼，且模糊性也不是安全控制。擁有 /orders/{their-uuid} 合法存取權限的客戶應該能夠查看它，但 /orders/{someone-elses-uuid} 仍必須被您的存取檢查拒絕。 UUID 隱藏訂單號碼以防止隨意檢查，並防止透過枚舉進行統計分析，但您的身份驗證和授權邏輯仍然由您的應用程式程式碼負責。保護是分層的：UUID 阻止識別碼本身的資訊洩漏，並存取控制強制誰可以對該識別碼進行操作。
這不包括什麼 - 隨機鍵的索引效能權衡，在單獨的帖子中討論
操作邊界很重要，因為 UUID 修復了 ID 本身的資訊洩漏，但不會取代存取控制機制。如果客戶擁有 API 金鑰和足夠的權限，他們仍然可以向您的系統發出請求。他們可以存取的範圍由您的權限模型和角色定義決定，而不是 ID 格式。 UUID 的好處純粹在於，識別碼會停止向任何可以觀察到它的人廣播數量、序列和生長資料。精心設計的系統將 UUID 不透明度與對 API 的每個請求進行明確存取控制檢查相結合。
重點：將公共引用與內部金鑰分開 - ToolAcre 產生器為公共端提供 CSPRNG 支援的 UUID
實際的遷移可以透過逐步支援兩種格式來避免出現問題。如果您對端點進行版本控制，v1 API 可以繼續傳回整數 ID，而 v2 傳回 UUID。客戶按照自己的步調過渡，無需協調切換。您的內部資料庫查詢保持不變：它們仍然按整數 id 進行過濾，因為您的索引是基於該列構建的，並您的外鍵引用它。僅傳回給客戶端的資料發生變化。 ToolAcre UUID 產生器產生您將使用的版本-4 格式；每個輸出都是正確的 RFC 9562 UUID 準備用於儲存、部署和逐步遷移場景。