開發者工具 · UUID 產生器
為什麼 crypto.randomUUID() 在 HTTP 頁面上失敗：安全上下文解釋
· 工作原理
uuid 密碼學 瀏覽器 API
crypto.randomUUID 在本機和 HTTPS 上工作，然後在純 HTTP 臨時主機上消失。這篇文章解釋了該行為背後的安全上下文規則，以及如何在適用的地方安全地產生 UUID 。
登台時出現 TypeError，其他地方都很好 — 症狀和導致它的環境差異
開發人員在本機上檢查他們的工作：3000 並 UUID 產生器運作正常。他們部署到 http://staging. 內部暫存。例子。 com（公司 LAN 上的純 HTTP）並程式碼拋出 TypeError: crypto.randomUUID is not a function。生產中相同的程式碼在 https://example. com 上運作良好。這種不一致令人困惑，直到他們閱讀 MDN 檔案：crypto.randomUUID 僅限於安全上下文。安全性上下文是 HTTPS 或 localhost；根據瀏覽器規則，LAN 上的純 HTTP 來源並不安全，即使網路是私有的。修復方法是使用 crypto.getRandomValues 進行手動位元操作，或將臨時伺服器升級到 HTTPS。引入安全上下文規則是為了防止敏感 API 洩漏到未加密的連線。
什麼是安全性上下文 — 為 HTTPS 來源和本機保留某些 API 的瀏覽器規則
透過純 HTTP 的頁面可能會被網路攻擊者攔截；將加密 API 暴露給此類頁面將使攻擊者能夠使用受損的 API 產生識別碼。 HTTPS 會對頁面和所有 API 通訊進行加密，以便網路上的攻擊者無法攔截或修改程式碼。本機被視為本質上安全的，因為它只存在於本機上並不能透過網路被攔截。根據定義，任何其他 HTTP 來源（LAN 位址、沒有 HTTPS 的公共網域、轉送到 HTTP 的反向代理）都是不安全的。 Web Crypto API 分為兩個函數：crypto.randomUUID（僅限於安全上下文）和 crypto.getRandomValues（在安全性和非安全性情境中均可使用）。兩者都使用相同的作業系統 CSPRNG。
Web Crypto 的哪些部分是門控的 - crypto.randomUUID 和 crypto.subtle 需要安全上下文，而 crypto.getRandomValues 不需要
的差異在於 getRandomValues 不會隱藏您正在使用加密技術的事實；使用它的頁面必須明確要求隨機位元組。 randomUUID 函數很方便，還可以強制執行安全性上下文。如果您的應用程式需要在非安全性頁面上產生 UUID，則必須使用 getRandomValues 並手動設定版本和變體位元。 RFC 9562 指定位元操作：將位元組 6 設定為 (byte6 & 0x0f) |版本 4 為 0x40，位元組 8 為 (byte8 & 0x3f) RFCx80 | ToolAcre 函式庫正是這樣做的，作為 randomUUID 不可用時的後備方案。重現失敗：從不被視為潛在可信任的普通 HTTP 來源提供一個簡單頁面。檢查 randomUUID 是否公開，然後比較 getRandomValues，Web Crypto 參考在不安全的上下文中允許這樣做。
從 getRandomValues 建置 v4 UUID — 當 randomUUID 遺失時，屏蔽和格式化回退讓您保持在 CSPRNG 上
透過 HTTPS 提供的檔案中的相同程式碼可以公開 randomUUID。如果生產報告“randomUUID 不是函數”，請先檢查來源是否為安全上下文，然後驗證瀏覽器支援以及另一個腳本是否替換了加密物件。補救措施可能是 HTTPS 或明確設定 UUID 位元的 getRandomValues 實作。 Math.random polyfill 並不是一個等效的後備：它在刪除加密來源合約的同時重現形狀。僅斷言破折號和版本數字的測試將錯過該替換，因此請檢查來源路徑以及結果字串。
工作範例 — 在 http:// 來源上重現故障並確認修復
但標識符現在是可預測的。從您的系統捕獲一些 UUID 的攻擊者可以預測下一個。如果應用程式錯誤地將此類識別碼視為持有者憑證，則可預測性將成為授權失敗而不是外觀缺陷。正確的策略是將伺服器升級到 HTTPS（對於任何具有身份驗證或敏感資料的頁面來說始終是正確的舉措）或使用具有明確位元操作的 getRandomValues（這需要更多程式碼，但在加密方面是合理的）。安全上下文由瀏覽器強制執行；您無法透過配置或環境變數來解決它。 ToolAcre 產生器透過 HTTPS 部署，因此 crypto.randomUUID 可用。當您在工具中產生 UUID 時，它會使用 randomUUID（如果安全上下文檢查通過）或具有位元操作的 getRandomValues（如果您使用純 HTTP，儘管這種情況很少見）。
為什麼你不應該使用 Math.random 進行填充——誘人的捷徑及其帶來的安全成本
兩條路徑都不會退回到 Math.random。如果您正在建立自己的 UUID 產生器並針對非安全性來源，請使用 getRandomValues 並自行執行位元操作。在 HTTPS 和 localhost 上進行測試以確認 randomUUID 有效，然後在 http:// 來源上進行測試以確認 getRandomValues 後備正確。了解安全上下文限制有助於您設計部署策略。如果您的應用程式必須在沒有 HTTPS 的私人 LAN（遺留基礎架構、嵌入式系統）上執行，那麼 getRandomValues 後備方案就是您的前進道路。如果可以選擇，請在所有地方升級到 HTTPS； Let's Encrypt 是免費的，而且投資在整個應用程式的安全性上得到回報。本機上的開發沒有限制，因此在部署到生產環境之前，請在本機主機和 HTTPS 暫存上測試您的 UUID 產生器。生產應始終採用 HTTPS。
這不包括伺服器執行時，例如 Node.js 和 Deno，它們在沒有安全上下文規則的情況下公開 API
此限制不是錯誤或麻煩；而是錯誤。它是一種安全功能，可以防止意外發生並迫使您考慮加密。更廣泛的模式是 Web 加密 API 由安全上下文控制。 crypto.getRandomValues，加密。微妙的。加密，加密。微妙的。 generateKey，以及所有其他敏感操作都需要 HTTPS 或 localhost。沒有例外，沒有覆蓋，沒有辦法停用檢查。單一不安全的頁面會破壞使用者的安全保證。即使您小心地僅在某些頁面上使用加密 API，錯誤（或包含 UUID 產生器的依賴項）也可能會將隨機產生洩漏到未加密的頁面。 ToolAcre 產生器在程式碼層級強制執行此操作：如果 randomUUID 不可用（非安全性上下文），它會使用 getRandomValues，該方法可用，但會提醒任何程式碼審查者正在發生異常情況。
重點：修復來源，而不是產生器 — ToolAcre 透過 HTTPS 提供服務，因此其產生器設計為在安全性上下文中執行
更好的是，如果安全上下文確實不可用（在 getRandomValues 也不可用的環境中，這種情況很少見，但在較舊的或嵌入式系統中是可能的），它會拒絕產生標識符。將現有系統遷移到 HTTPS 以支援安全加密 API 是一個常見的項目。從產生 UUID 的來源（您的驗證伺服器、API 後端或關鍵應用程式服務）開始。取得 TLS 憑證（Let's Encrypt 免費提供）。將您的 Web 伺服器配置為預設提供 HTTPS 服務，並將 HTTP 請求重新導向至 HTTPS。使用多個瀏覽器和 API 用戶端進行測試，以確保一切正常。然後審核您的程式碼以查找可能在未加密頁面上呼叫的任何剩餘加密 API 並修復它們。 ToolAcre 產生器採用 HTTPS；如果您正在使用它，那麼您已經成功了。