私鑰存在裝置的硬體中

DBSC 的核心運作方式，是在登入時產生一組金鑰對。私鑰存在裝置的硬體中，無法匯出；公鑰交給網站保存。

網站的 session cookie 改為短效，例如 10 分鐘(時間沒硬性規定)。Cookie 快過期時，瀏覽器用私鑰對伺服器給的挑戰（challenge）簽章，證明自己仍是當初登入的那台裝置，伺服器才發新的短效 cookie。

整體流程分成幾步。以下沿用 Chrome 文件中的範例路徑 /StartSession 與 /RefreshEndpoint，兩者都可由網站自訂，不是規範要求的固定路徑：

1. 登入回應加上 Secure-Session-Registration: (ES256 RS256); path="/StartSession" 標頭，宣告可接受的簽章演算法與註冊端點。
2. 瀏覽器呼叫 path 指定的註冊端點，以 Secure-Session-Response 傳送簽署過的 JWT proof；公鑰放在 JWT 標頭的 jwk 欄位，採用 JWK 格式。伺服器驗證後將公鑰與 session 綁定，回傳 session 設定（session_identifier、scope、credentials，以及選填的 refresh_url），並在此範例中將長效 cookie 換成短效 cookie。
3. 短效 cookie 缺少或過期、需要續期時，瀏覽器呼叫設定的續期端點（本例為 /RefreshEndpoint）。若需要新的 challenge，伺服器回 403 與 Secure-Session-Challenge；瀏覽器以 Secure-Session-Response 帶上簽署 challenge 的 JWT proof，伺服器驗證成功後回 200，透過 Set-Cookie 核發新的短效 cookie。若已有可用的 challenge 與有效 proof，就不必每次先回 403；瀏覽器也可能在 cookie 過期前預先續期。

這裡要區分「固定的協定名稱」與「網站自行設定的值」：

名稱與格式可對照 DBSC 草案的格式定義；上述端點名稱出自 Chrome 官方實作範例。

Chrome 文件也建議同時保留兩種 cookie：長效 cookie 只用來重新換發短效 cookie，短效 cookie 才用於一般請求與敏感操作。

一般操作與 AJAX 請求如何受到保護（透明續期機制）

聽到這邊可能直覺會懷疑：既然 DBSC 綁定了私鑰，那登入之後網頁每次點擊、換頁，或是前端發出的非同步 AJAX（fetch()、XMLHttpRequest）請求，難道每次都要前端 JavaScript 手動加簽章嗎？

答案是不用。DBSC 把整個防護拆成「日常通行」與「到期換證」兩段機制，各自的驗證對象與時機不同：

• 前端不必替每次 AJAX 加上 DBSC 續期標頭或手動產生硬體簽章：在短效 Cookie 尚未過期（例如 10 分鐘內）的期間，瀏覽器會照原本 Cookie 規則自動夾帶它，前端呼叫起來跟一般請求沒有差別。
• 後端對受保護的業務請求依然要逐次驗證：每次頁面或 AJAX 請求進來，後端都必須檢查登入狀態與這顆短效 Cookie 是否有效，只是這段檢查通常集中在共用的登入函式或 middleware 裡，不必每支 API 重寫。若短效 Cookie 已過期且沒能續期成功，就算長效登入 Session 還在，後端也必須回傳 401 拒絕請求。
• 硬體私鑰只有在 refresh 續期時才會出場：當短效 Cookie 過期（或瀏覽器預先續期）時，瀏覽器會在背景暫停該次請求，先向 refresh 端點完成 TPM 或 Secure Enclave 的 challenge 簽章驗證，拿到新的短效 Cookie 後才把原本的請求放行送出（參考 Chrome 的 DBSC 流程說明）。

正因為普通的資料請求只有驗「短效 Cookie」，而不是每次都重新向硬體證明當下持有私鑰，DBSC 才做得到低延遲與前端零改動。相對地，這也是它的安全邊界：如果這顆短效 Cookie 在有效期限內就被偷走，在過期前的這幾分鐘空窗期裡，攻擊者依然能直接重放使用；DBSC 擋掉的是對方在過期之後繼續憑藉長效 Session 無限續命。

每次驗算會拖垮效能嗎？硬體簽章與伺服器負擔評估

既然牽涉到非對稱加密與硬體簽章，另一個常見疑慮是效能損耗，使用者的電腦會不會因為每次 AJAX 請求都要簽章而卡頓？伺服器端會不會因為每次請求都要驗簽，而增加負載？

終端使用者設備（TPM 簽章）：TPM 2.0 晶片進行硬體簽章單次大約需要 30 到 100 毫秒。如果每個 HTTP 請求都簽章，網頁操作必定嚴重卡頓。但因為只有在短效 Cookie 過期換發時（例如每 5 到 15 分鐘一次）才會呼叫 TPM 簽章一次，平時一般的 AJAX 與網頁瀏覽毫無延遲，使用者完全感覺不到開銷。

伺服器端（簽章驗證）：伺服器在處理 99% 的一般業務請求時，只做傳統的 Cookie 查表（Redis 或 Session 讀取只需 0.1 毫秒），完全不涉及密碼學運算。只有在每數分鐘一次的 refresh 端點上，伺服器才需要呼叫 OpenSSL 驗證一次 ES256 簽章。現代伺服器 CPU 透過軟體驗證一次 P-256 簽章僅需約幾毫秒，對後端負載微乎其微。

什麼，你說你用的是便宜的 share hosting 虛擬主機？那就更不會有問題了，因為你根本沒有資格去看各種真實的系統負載資訊，還不如多擔心同一台機器上的惡鄰居，或是廠商在看不到的地方 costdown。

硬體與平台需求

使用 DBSC，電腦不需要額外外接 YubiKey 之類的硬體安全金鑰，它使用電腦內建的硬體：

根據 Corbado 在 2026 年 10 月的檢查，Edge 147 也支援 DBSC，範圍同樣限於 Windows 與 macOS。

Safari 則是沒有宣布實作，Mozilla 的立場是反對。

Safari 在 WebKit standards-positions #281 中對備份還原體驗表達疑慮，似乎是認為這種讓一部分資訊永久鎖死在單機硬體晶片的技術，會嚴重破壞 Apple 生態系強調的跨裝置 iCloud 備份還原、無縫接續的體驗。

而 Mozilla 的官方立場mozilla/standards-positions #912: Device Bound Session Credentials則是反對(negative)。

主要質疑 DBSC 的短效 Cookie 在過期前，仍有時間差窗口(Replay Window)造成被濫用的機會。而且如果攻擊者已經取得電腦權限，就算有 DBSC，還是無法阻止在電腦開機時產生一個新的 Session，或是惡意程式還是可能把你新的登入綁到它控制的裝置上。

網站開發團隊必須選擇相容策略

有些 DBSC 的官方介紹常讓人感覺「沒有 TPM 或 Secure Enclave 的裝置會自動退回一般 Cookie，不會造成登入失敗」，例如How DBSC works裡面有寫到:

If a user's device does not support secure key storage, DBSC gracefully falls back to standard behavior without breaking the authentication flow.

這句話只說了一半，若照字面理解，很容易在實作時踩坑。

實際上瀏覽器端的所謂「退回」，只是指不支援 DBSC 的瀏覽器（如 Safari、Firefox、Linux 或無 TPM 的舊電腦）收到 Secure-Session-Registration 標頭時，會直接忽略該標頭，既不會報錯直接中止整個流程、也不會主動發起任何註冊或換發流程。

真正決定使用者會不會被卡在登入流程的，是網站程式自己後端程式的驗證策略設計：

1. 強制嚴格模式（Strict Mode）：若伺服器只核發短效 Cookie，並在後續所有 API 與頁面強制要求 DBSC 綁定憑證，那麼不支援的裝置因為根本無法生成那些特殊標頭與短效 Cookie，登入後的下一步就會被 403 error 擋住，讓不支援的手機瀏覽器或裝置直接在登入路徑卡死。
2. 寬鬆雙軌模式（Permissive Mode）：若網站要維持相容性，後端就必須自己額外實作多段相容邏輯。登入時必須同時發放傳統長效 Cookie，且在每一次權限檢查時進行分支判斷：只有在該 Session 成功綁定 DBSC 時，才強制檢查短效 Cookie。未綁定或不支援的裝置則退回傳統驗證邏輯。

一旦後端採用寬鬆雙軌模式，就必須承擔降級攻擊的風險。雖然已經完成綁定的 Session 不能中途退回舊驗證，但只要未綁定也允許通行，有心人士在登入或建立新 Session 時，只要想辦法讓網站程式不要帶上註冊標頭（例如偽裝成不支援的瀏覽器 User-Agent），或收到標頭後直接忽略不註冊，就能拿到一組未綁定的傳統 Session 照常運作，這也是實作時最掙扎的架構抉擇。

對使用者的影響：多數時候完全無感

正常使用時，使用者看不到任何提示，也不會像 Passkey 那樣跳出作業系統驗證視窗，也不需要 MFA 那樣有額外的操作步驟，網頁瀏覽器會在背景完成簽章與換發。

使用者只會在少數情況下察覺，例如更換或重灌電腦、TPM 金鑰失效、refresh 的 api endpoint 無法連線等等，這些情況下 session 無法更新續約，使用者會看到身分驗證失敗的訊息，甚至需要重新登入。正常運作情況下是完全無感的。等下後面會開始講有感的地方，例如某些設計可能造成頁面可以載入，但操作時一直提示權限驗證錯誤之類的...

無感，表示根本沒人會注意到這個功能的存在，也就代表導入此功能的相關技術人員，不會成為有功的猴子。但是碰到使用者的設備沒有 TPM，可能會無法登入、或是登入後的操作被迫中斷，反倒這些才會引起抱怨和客訴。

TPM 是不是在哪聽過? 沒錯，就是那個害一堆人安裝 Windows 11 還要想辦法繞過，或是因為無法升級，害一堆人每天看 Windows 10 終止支援提示畫面的玩意。

本來以為手機也能用

原本預期 DBSC 能同時保護桌機與手機登入。實際上 Chrome 的 Android 與 iOS 都不支援，手機沒有可用的 TPM 或 Secure Enclave 介面給瀏覽器呼叫。會員若以手機為主，這個機制幾乎碰不到他們。

本來以為隨便一台 Windows 電腦都能用

原本預期只要是 Windows 10 以上就有 TPM。實際上很多舊電腦沒有 TPM 2.0，Windows 11 的硬體門檻因此排除它們。部分使用者寧願停留在 Windows 10 而不升級 Windows 11，結果這些仍在使用的系統無法受惠於 DBSC，也讓網頁系統的資安防線多了一個缺口。

本來以為可以跨裝置登入

原本以為 DBSC 會綁定 Chrome 的使用者設定檔(chrome profile)，因此同一個 Google 帳號在另一台電腦登入 Chrome 後，綁定應該會跟著同步?

實際上綁定的是那台電腦 TPM 或 Secure Enclave 中的私鑰，私鑰無法匯出，也不會隨 Chrome 同步。換一台電腦，即使是同一個 Chrome 帳號，也要重新登入並註冊一組新的金鑰。

這也代表使用者在多台電腦之間切換時，每台電腦都要各自登入一次，網站端會看到多組綁定，而不是一組。

本來以為「記錄是哪一台電腦做的」就能證明是誰

原本以為 DBSC 能在 log 裡記下「哪一台已登記的電腦」做了某個操作，進而證明是誰操作。實際上 log 只能記錄「哪一把已綁定的金鑰簽了這個請求」，無法證明操作者是本人。

• 同一台電腦可能有家人共用，或是已被惡意程式控制，簽章仍然有效。
• 金鑰對應的是裝置，不是人。若要記錄操作者，仍需要 session 對應到會員 ID，並在敏感操作上另外做應用層驗證。
• 若要做稽核，應記錄 session 識別碼、會員 ID、綁定 ID、時間與來源 IP，而不是只記錄「電腦」。

本來以為公鑰是電腦固定不變的識別碼

原本以為每台電腦在 TPM 內只有一把固定公鑰，能用來當作穩定不變的裝置指紋，甚至拿來跨站追蹤或抓出分身帳號。

實際上 W3C 與 Chrome 為了防止 fingerprinting，規範中強制要求「無法關聯性(Unlinkability)」，瀏覽器每次註冊 Session 都會向 TPM 請求生成一組全新且獨立的金鑰對。因此不同網站、甚至同一台電腦上的不同 Session（例如無痕視窗或重新登入），取得的公鑰都完全不同。公鑰只在「同一個 Session 生命週期內」有效，一旦登出或清除瀏覽器網站資料就會在本地被銷毀，無法當作長期的硬體識別碼。

本來以為隨便叫 AI 寫個 DBSC 就能動

現在遇到新技術，很多人習慣直接請 AI 生成範例程式碼，甚至直接大改專案。但 DBSC 屬於 2024 年後才逐步推進的前沿標準，程式碼橫跨網頁前後端、瀏覽器機制、作業系統 TPM/Secure Enclave、OpenSSL 橢圓曲線驗簽（ES256）、HTTP 403 Challenge-Response 流程，以及現有程式的使用者登入週期整合。

實測發現，像 Claude Haiku、GPT Luna、Gemini Flash 這種比較輕量低階的模型，或各類開源小模型，處理這類模型知識外的新東西，配上高密度的全端架構，非常容易出現幻覺和錯誤：

• 官方文件明明寫過位置與演算法，還是會照寫 REST API 的習慣跑去 JSON body 撈 Secure-Session-Response，或跑到 payload 找公鑰，沒注意到它放在 JWT header 的 jwk 裡。
• 直接把 JWT 原始的 64-byte ES256 簽章和 JWK 座標塞進 openssl_verify()，漏掉先轉成 ASN.1 DER 簽章與 SPKI PEM 公鑰這一步。
• 跟其他加密機制搞混，以為要寫前端 JavaScript 呼叫 WebCrypto 自己產金鑰、算簽章再塞進每次 AJAX，沒分清楚哪幾段已經由瀏覽器底層接管。
• 寫 /RefreshEndpoint 時照一般 API 習慣，換完新 Cookie 就回傳 {"success": true} JSON，瀏覽器一判定格式無效就直接終止這組綁定。
• 只盯著標頭收送，卻沒處理原本系統的 Session 連動，像是直接拿 PHPSESSID 當 session_identifier 結果一換 ID 就斷線，或是漏掉第三方登入跟登出撤銷的入口。
• 沒替 Session 加鎖，SPA 一有並行請求就會互相蓋掉綁定資料；Chrome 在背景主動換票時，也沒替已經送出、還沒跑完的請求多留一點寬限期。
• 直接變成可繞過的漏洞，例如驗證分支不小心讓已綁定的 Session 退回舊驗證、拿未驗證的用戶端 Cookie 自動補登，或是沒確認過就讓人換掉綁定公鑰等等。
• 沒把一次性的 jti 存進共享儲存區比對並立即作廢，或是瀏覽器帶快取舊 proof 重試時只回錯誤 JSON 卻沒給新 challenge，最後就卡死在 challenge mismatch。

在這種跨底層硬體、密碼學與新興網路標準的場景下，輕量模型通常只能寫出看似煞有其事，卻無法跑通/假裝能跑通的半套程式碼。必須使用具備深層邏輯推演能力的旗艦高階模型（如 Claude Sonnet / Opus、GPT Sol 以上頂級推論模型），並餵給它明確的規範文件與各種 log，才能實作出真正能落地的安全程式。

以下透過各種案例，比較幾種常見的 Session 與驗證架構，分別討論無資料庫的簡易登入，以及整合資料庫與第三方登入的帳號系統。

以下範例的網域、自訂 Cookie、欄位、資料表與儲存鍵皆為示意，不對應特定服務。註冊與續期路徑沿用官方文件的 /StartSession、/RefreshEndpoint；PHP 與 DBSC 的標準名稱保留原名。

沒有 DBSC 時，本來的防禦擋不住什麼

這套架構只在登入時比對固定密碼，後續請求則靠 PHPSESSID 找回伺服器端的 example_signed_in = true。攻擊者若取得仍有效的 Session Cookie，就能從自己的裝置沿用登入狀態，不需要破解密碼雜湊，也不需要修改伺服器上的登入旗標。沒有資料庫並不會消除這個風險，因為這裡缺少的是對原裝置持有金鑰的驗證。

• Cookie 安全屬性無法阻止已外洩憑證被重放：Secure 限制 Cookie 透過 HTTPS 傳送，HttpOnly 限制網頁 JavaScript 直接讀取，SameSite 限制跨站請求攜帶 Cookie。這些措施各有用途，但若本機惡意程式仍取得了 Cookie，攻擊者就能在另一台裝置向原網站發出請求。這些屬性的防護範圍可參考 OWASP 的 Session Cookie 說明。
• 縮短期限與更換 Session ID 只能限制使用窗口：伺服器端的到期檢查與 session_regenerate_id() 有助於降低風險，但新 ID 仍是可攜帶的憑證。如果惡意程式持續取得新 Cookie，攻擊者仍可能繼續沿用；若只有閒置逾時、沒有絕對到期時間，攻擊者持續送出請求也可能讓 Session 保持有效。
• 更改固定密碼不會自動撤銷既有登入：依這個只檢查登入旗標的設計，密碼變更只影響下一次登入。若沒有額外檢查密碼版本或主動讓舊 Session 失效，先前被複製的 Cookie 仍可能繼續使用。
• 缺少獨立的登入紀錄與撤銷機制：單靠登入旗標，無法列出各次登入、辨識哪些 Session 需要撤銷。若要製作遠端登出、一次撤銷所有登入憑證，需要另外設計和實作各種機制，這些功能不會從天上掉下來。

導入 DBSC 後，已綁定的 Session 除了登入旗標，還要有有效的短效 Cookie；續期則必須證明持有綁定私鑰。攻擊者只複製 Cookie 到另一台機器，就無法持續換發憑證。

不過，短效 Cookie 在伺服器接受的期限內仍可能被 replay，而直接操控受害者瀏覽器的 XSS 或本機惡意程式，也仍在 DBSC 草案列出的防護範圍之外。固定密碼的保護、Session 撤銷與 XSS 防禦仍須自己處理。

即使登入邏輯很少，導入 DBSC 仍須處理綁定資料、短效 Cookie 與既有 Session 的生命週期，工作不只是在登入成功時多送一個標頭。

沒有資料庫，綁定資料一起放在 Session

DBSC 需要網站伺服器端記住每個綁定的公鑰與綁定 ID，但我們就是沒有要在伺服器上用資料庫、Redis、檔案等機制存入任何東西，所以就先把它們放進 Session，與登入狀態一起保存。綁定 ID 仍要另外隨機產生，不能直接拿 PHPSESSID 充當，否則 session_regenerate_id() 更換 ID 時，瀏覽器記住的 DBSC 識別值也會跟著失效。

這種做法讓綁定的壽命受 Session 限制：Session 檔被清掉、換了儲存位置，或更換 Session ID 時沒有保留資料，綁定都會一起消失。因為沒有獨立的撤銷清單，撤銷綁定時應讓對應的登入狀態一起失效。不能只刪掉綁定資料卻保留 example_signed_in = true，否則下一次請求會被當成未綁定的 Session，退回原本的驗證。

登入入口與註冊 challenge 要一起處理

很多簡單程式會有一條給表單 POST 的登入路徑，另一條給 fetch 或 AJAX 呼叫的登入路徑。Secure-Session-Registration 必須出現在登入成功的那個回應上，如果只改其中一條，另一條登入的使用者就不會被綁定，而且不會有任何錯誤訊息。導入前要先盤點所有會寫入登入旗標的地方。

以下示意放在密碼與 CSRF 驗證通過後、尚未輸出回應本文的位置。$dbscEnabled 是網站的設定開關，$dbscRegistrationCandidate 是伺服器依瀏覽器資訊粗篩的結果，兩者都不是完成硬體綁定的證明：

session_start();
session_regenerate_id(true);
$_SESSION['example_signed_in'] = true;

if ($dbscEnabled && $dbscRegistrationCandidate) {
    $challenge = bin2hex(random_bytes(32));
    $_SESSION['example_registration'] = [
        'challenge' => $challenge,
        'expires_at' => time() + 60,
    ];

    header('Secure-Session-Registration: (ES256); path="/StartSession"; challenge="' . $challenge . '"');
}

註冊端點收到的是 Secure-Session-Response 標頭中的 JWT proof，不能把請求本文當成一般 JSON，直接讀取 key 就完成綁定。依 DBSC 草案的 proof 格式，註冊公鑰位於 JWT header 的 jwk；伺服器必須驗證允許的演算法、簽章及 payload 的 jti 是否符合尚未過期的註冊 challenge，成功後才保存公鑰與綁定 ID，並消耗該 challenge。

註冊成功後，伺服器核發短效 Cookie，並回傳設定。例如保留原本的 PHP Session Cookie，另用 example_bound 當作短效憑證：

{
  "session_identifier": "random_binding_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": false
  },
  "credentials": [
    {
      "type": "cookie",
      "name": "example_bound",
      "attributes": "Path=/; Secure; HttpOnly; SameSite=Lax"
    }
  ]
}

這份 JSON 只告訴瀏覽器要管理哪個 Cookie，實際憑證仍要透過 Set-Cookie 核發。短效憑證的摘要與到期時間也要保存在伺服器端，不能只相信瀏覽器會遵守 Max-Age。

程式碼前後對比：從登入旗標到短效 Cookie 檢查

原本受保護的頁面或 API，只檢查登入旗標：

session_start();

if (empty($_SESSION['example_signed_in'])) {
    http_response_code(401);
    exit;
}

// 驗證通過，執行業務操作。

導入 DBSC 後，若這個 Session 已完成綁定，還要檢查短效 Cookie。只判斷 Cookie 是否存在並不足夠，還必須比對憑證值或摘要，以及伺服器端到期時間。不能把「有帶 Cookie」當成已完成憑證驗證。

以下示意一般業務請求的驗證方式。isExampleCredentialValid() 是示意函式，負責比對憑證摘要、伺服器端到期時間，以及它是否屬於目前的綁定；這裡省略驗簽與憑證管理函式的實作：

session_start();

if (empty($_SESSION['example_signed_in'])) {
    http_response_code(401);
    exit;
}

$binding = $_SESSION['example_binding'] ?? null;

if ($binding !== null) {
    $credential = $_COOKIE['example_bound'] ?? '';

    if (!is_string($credential) || !isExampleCredentialValid($credential, $binding)) {
        http_response_code(401);
        exit;
    }
}

// 已綁定的 Session 通過短效憑證檢查後，才執行業務操作。

這裡採用寬鬆雙軌模式：未綁定的舊 Session 或不支援的裝置，仍走原本的登入驗證；一旦綁定成功，就依伺服器保存的狀態要求短效 Cookie，不能因為某次請求少了標頭或改了 User-Agent 就退回舊驗證。保留的長效 PHP Session Cookie，在已綁定的狀態下也不能單獨通過業務驗證。

一般 API 不應要求每次都帶 Sec-Secure-Session-Id。這個標頭是 DBSC 草案中 refresh 請求使用的識別值；日常頁面與 AJAX 仍是驗證短效 Cookie，不是每個請求都重新驗硬體簽章。就算前端沒有自己補任何 DBSC 標頭，瀏覽器還是會照 Cookie 規則把 example_bound 送出來，後端照樣要跑上面那段 isExampleCredentialValid() 檢查。如果網頁放了一段時間突然撈不到資料，可能就是請求跑到這一步時，example_bound 過期或沒帶上來而被擋掉了。

refresh 與前端請求的分工

短效 Cookie 缺少或過期時，Chrome 會嘗試先暫停請求，呼叫 refresh，再放行。refresh 端點需要完成以下工作：

1. 透過原本的 PHP Session 與 DBSC 綁定 ID 找到公鑰，確認登入與綁定仍有效。
2. 若需要新的 challenge，保存其有效期限並回傳 403 與 Secure-Session-Challenge；收到 proof 後，驗證簽章與 challenge，並處理已消耗或過期的挑戰。
3. 驗證成功後，更新伺服器端的短效憑證狀態，以 Set-Cookie 重新核發短效 Cookie；失敗則不續期。

這個流程不需要 Redis 或會員資料表，狀態可以跟著 PHP Session 保存。refresh 仍應考慮並行請求與提前續期，不能假設只有 Cookie 過期後才會被呼叫。

前端業務程式不用自己操作金鑰或替每次 fetch 加簽章。不同登入架構都可以集中處理登入失效，例如：

async function secureFetch(url, options = {}) {
    const res = await fetch(url, options);
    if (res.status === 401) {
        showExampleSignInNotice();
        return null;
    }
    return res;
}

其中 showExampleSignInNotice() 是提示使用者重新登入的示意回呼，401 本身不代表一定是硬體簽章失敗。若業務 API 用 403 表示權限不足，前端也要和登入失效分開處理。

登入狀態仍在，有些頁面能正常顯示資料，功能卻不能用

導入 DBSC 後，很常遇到一種讓使用者覺得莫名其妙的現象：Session 裡的登入旗標明明還在，網頁也打得開，但是一旦點選裡面的按鈕要操作，就連連報錯登入逾時、請重新登入、401 error 之類的錯誤；甚至有些頁面按瀏覽器重新整理時，資料卻又都能正常顯示。

長效 PHP Session 可能保留數天，短效 Cookie 卻只有幾分鐘，因此可能出現兩類問題：不同入口的驗證條件不一致，或是 DBSC 續期失敗。兩者也可能同時發生。

第一種情況是新舊程式的後端驗證條件沒有對齊，常見於「早期傳統 PHP 頁面」與「後來才加的 AJAX 功能」混用的網站。傳統後端頁面在輸出整頁 HTML 或處理表單送出時，如果仍只檢查原本的 example_signed_in = true 和既有權限值，但比較晚開發的按鈕或操作 HTTP API 卻加上了短效 Cookie（例如 example_bound）與綁定檢查；只要短效 Cookie 失效或沒帶上來，點選頁面功能就會連連報錯 401，偏偏按瀏覽器重新整理頁面時，整個頁面的資料卻又正常顯示出來。若是「先載入外皮、再用 AJAX 塞資料」的頁面，更會變成外框打得開、資料卻一片空白。

要避免這種只保護到一半的狀況，受保護的傳統 PHP 頁面入口、表單處理與所有 AJAX 資料 API（包含查詢登入狀態的端點），在處理請求時都應該共用同一套登入與短效憑證檢查邏輯。前端 AJAX 收到 401 時，也要明確提醒使用者重新登入，並把編輯中的內容先留住，讓重登後能接著操作，別把 401 失敗直接顯示成「沒有資料」。

第二種情況則是全站本來就以 AJAX 呼叫 HTTP API 為主、後端驗證也已經全部對齊，剛登入的前幾分鐘功能都正常，但短效 Cookie 過期後，若又無法成功續期，後續業務 API 就會持續回 401（參考 Chrome 官方流程說明）。檢查會發現 PHP Session 裡的登入旗標與綁定資料明明都還在，真正的問題其實是瀏覽器向 refresh 端點換證失敗。

以下列出兩個可能造成續期失敗的實作錯誤：

refresh 成功回應誤用一般 AJAX 的 JSON 格式：伺服器驗簽成功並透過 Set-Cookie 核發新的短效 Cookie 後，若照一般 API 習慣回傳 {"success":true} 或 {"status":"ok"}，就會踩到瀏覽器底層的協定解析規則。

依 DBSC 規格，在既有綁定的續期請求上，伺服器可以回傳空本文（完全空白）的 HTTP 200；若 HTTP 200 回應帶有本文，就必須是完整有效的 DBSC Session 設定（包含 session_identifier、scope、credentials 等必要欄位，refresh_url 為選填），回傳完整且與原本相同的設定也可以，但不能只是一般成功 JSON。缺少必要欄位時，瀏覽器會判定設定無效並直接終止該次 DBSC 綁定。

一旦瀏覽器終止這組綁定，就算伺服器還留著公鑰和綁定紀錄、後來也修好了 refresh 程式，瀏覽器也不會自動恢復續期；在本文的設計下，使用者仍需要重新登入並完成 DBSC 註冊。

challenge 驗證與快取重試沒有照協定回 403：當後端需要瀏覽器重新簽署挑戰碼時，refresh 端點必須依協定回傳 HTTP 403 與 Secure-Session-Challenge 標頭，讓瀏覽器自動取得新挑戰碼重試；這套給瀏覽器底層處理的續期回應，不能與一般業務 API 的登入失效回應混用。

另外，瀏覽器有時會拿先前快取的 challenge 或 proof 來續期，但伺服器端那份 challenge 早就用過並清掉了；這時就算簽章本身驗得過，也不能直接放行，後端一樣要回傳 HTTP 403 並附上新的 Secure-Session-Challenge 標頭讓瀏覽器重簽（細節見 DBSC 草案的 challenge 快取與續期規則）。若只回一般的 403 錯誤 JSON 卻沒給新 challenge，瀏覽器就可能反覆送出同一份舊 proof，始終換不到新 Cookie。

多套驗證流程要分開保存狀態

如果同一套系統有多種驗證流程，且共用 Session 儲存與 Cookie 範圍，綁定欄位和短效 Cookie 就要分開命名，避免其中一條流程登入或登出時覆蓋另一條流程的狀態。

不同驗證流程可共用應用程式層的啟用開關，先只對 Chrome 桌面版送出註冊標頭。User-Agent、Client Hints 或前端回報只能用來粗篩，不能證明 TPM 可用；是否完成綁定，仍要以伺服器驗證註冊 proof 的結果為準。註冊尚未成功時保留原本登入流程，成功後則不能靜默降級，並應記錄成功、失敗與未啟用的數量。

如果網站前方有 CloudFront 等 CDN，務必要確認註冊與 refresh 端點不要被 CDN 快取，且 Cookie、Sec-Secure-Session-Id、Secure-Session-Response 等必要請求標頭能送到源站，回應的 DBSC 標頭與 Set-Cookie 也能回到瀏覽器。refresh 會卡住原本的業務請求，Session 讀寫與驗簽要在 CDN 的逾時限制內完成。

偵錯比功能本身更花時間

這類程式沒有太多日誌，註冊或 refresh 失敗時，瀏覽器端幾乎看不到錯誤。實務上需要先加臨時的偵錯日誌，記錄後端收到的請求標頭名稱、Secure-Session-Response 是否存在、challenge 是否還在 Session 裡，以及驗證失敗的原因。這些資訊有助於確認中間層是否有轉送標頭、公鑰位置是否讀對。

續期成功的判斷還要多看一層：伺服器驗簽成功，不代表瀏覽器接受了回應。登入狀態、伺服器綁定狀態、短效 Cookie 是否存在，以及瀏覽器的註冊與續期結果，要分開觀察。即使只有固定密碼加 Session 的簡單程式，導入 DBSC 後仍多出一套跨越伺服器、瀏覽器與硬體的生命週期，不能用登入當下成功一次就判定完成。

沒有 DBSC 時，本來的防禦擋不住什麼

案例一沒有資料庫，綁定資料與登入旗標都放在 Session；案例二有會員資料表，綁定資料可以獨立保存。兩者的差別是：案例一的 Session 只要被複製到另一台裝置，就能沿用登入狀態；案例二則可以查詢綁定資料、撤銷特定裝置的登入，或在帳號停權時撤銷所有裝置。

其他防禦缺口與案例一相同：固定密碼、Session 撤銷與 XSS 防禦仍須自己處理。即使有會員資料表，若沒有獨立保存綁定資料，仍無法阻止攻擊者在另一台裝置沿用登入狀態。

使用後端 Session 的實作機制基本上碰到的問題都一樣，不是因為用 PHP 就比較不安全，換成 Node.js、Python、.NET 或 Java 的問題也全部一樣。只要 Session 仍是伺服器端的登入旗標，攻擊者就能沿用被複製的 Cookie。

實作 DBSC，案例 1 的註冊標頭、challenge、短效 Cookie 檢查、refresh 與前端錯誤處理，在這裡都適用。差別在於登入入口更多，綁定需要關聯會員，而且必須能獨立查詢與撤銷。

在各登入入口完成應用程式綁定

除了表單或 AJAX 登入，還要盤點 WebAuthn 登入與 OAuth 回呼。每一條會寫入 $_SESSION['example_signed_in'] 與 $_SESSION['example_account_id'] 的路徑，都應在應用程式登入成功的回應中接上案例 1 的註冊流程，不能只改其中一條登入路徑而漏掉回呼。

使用者透過第三方登入成功，和應用程式的 DBSC 註冊是兩個步驟。這裡討論的是登入應用程式後建立自己的綁定；第三方登入回呼本身不代表應用程式已完成 DBSC 註冊。

把綁定與會員關聯，獨立於 PHP Session 保存

與只把公鑰放在 Session 的做法相比，會員系統可以另外建立綁定資料表，保存綁定 ID、會員 ID、公鑰、撤銷狀態及短效憑證資料。這是有資料庫後可採用的擴充設計，不是現有會員資料表會自動提供的能力。

以下只示意註冊 proof 驗證通過後的儲存差異；$verifiedPublicKeyJwk 必須來自已完成驗簽與 challenge 檢查的結果，不能直接信任客戶端送來的公鑰：

session_start();
$memberId = $_SESSION['example_account_id'] ?? null;

if (empty($_SESSION['example_signed_in']) || !$memberId) {
    http_response_code(401);
    exit;
}

$bindId = bin2hex(random_bytes(16));

// 示意函式：將綁定 ID、會員 ID、公鑰與初始憑證狀態寫入獨立儲存。
saveExampleBinding($bindId, $memberId, $verifiedPublicKeyJwk);
$_SESSION['example_account_binding_id'] = $bindId;

// 接著核發會員專用的短效 Cookie，並回傳對應的 session 設定。

綁定 ID 一樣不能直接使用 PHPSESSID。獨立保存後，session_regenerate_id() 不需要改變 DBSC 綁定 ID；但要保留 PHP Session 與綁定的對應，並明確設計 refresh 如何找到會員與公鑰。若採用獨立長效 Cookie 承載綁定 ID，它只能協助查找資料，不能單憑該 ID 通過驗證或換發憑證。

一般會員 API 可沿用案例 1 的短效 Cookie 檢查，再補上會員 ID 一致性與撤銷狀態檢查；refresh 也必須拒絕找不到、會員不符或已撤銷的綁定。公鑰已搬到資料表，不表示原本登入 Session 消失後就能直接恢復登入，這部分仍取決於網站選定的續期設計。

登出、帳號變更與撤銷要連動

案例 1 沒有獨立資料表，撤銷時讓對應的登入 Session 一起失效；會員系統則還要撤銷獨立保存的綁定，並清除對應 Cookie。只銷毀 PHP Session，卻保留仍能通過 refresh 的綁定資料，會留下未撤銷的續期路徑。

案例 2 有會員 ID 後，也能依帳號查出多個綁定，處理全部裝置登出、帳號停權或安全設定變更。哪些事件要撤銷目前裝置、哪些要撤銷全部裝置，必須和既有帳號管理流程一起決定。

另外要評估的風險

• 線上系統的使用者若以手機為主，實際覆蓋率會很低。因為手機的瀏覽器目前不支援 DBSC，在寬鬆雙軌模式下，手機端建立的 Session 本來就無法完成綁定、只能走傳統驗證邏輯；一旦這類未綁定的登入憑證遭竊，攻擊者依然能直接沿用，DBSC 在這群使用者身上完全派不上用場。
• 註冊當下若裝置已受惡意程式控制，攻擊者仍可能干預金鑰綁定，不能把註冊成功當成本機安全的證明。
• 涉及資料庫查詢與撤銷的 refresh 流程，必須在具備相關服務的測試環境驗證，光靠一般的程式語法檢查器，無法確認這些行為。

沒有 DBSC 時，本來的防禦擋不住什麼

這套架構表面上已經符合常見的安全實務：前後端分離、短效 JWT（10 分鐘）、長效 refresh cookie，cookies 的HttpOnly 與 SameSite 當然也是加好加滿。但在沒有 DBSC 的情況下，面對竊取攻擊依然有防不住的環節。

例如攻擊者在使用者電腦植入資訊竊取程式（Infostealer）。該程式繞過瀏覽器內部的 JavaScript 限制，直接由作業系統層級讀取 SQLite cookie 資料庫並完成解密。

1.雙 Cookie 同步外洩：由於短效存取 cookie 與長效 refresh cookie 都存在同一台電腦的瀏覽器中，惡意程式會一次把兩組 cookie 都打包帶走。

2.短效期間完全失控：維持高吞吐量，通常只做 JWT 本身的簽章驗證與過期時間檢查，不會每次向 PostgreSQL 查詢 example_sessions。攻擊者在自己的電腦直接帶上短效 JWT 呼叫 API，在 10 分鐘內可以任意執行查詢與操作。即便管理員或使用者在此時執行「登出」並在資料庫更新了 revoked_at，只要 JWT 還沒到期，攻擊者的請求依然會全數通過。

3.長效 Cookie 換發新存取權限：攻擊者只要用偷來的長效 refresh cookie 向伺服器發送換票請求，伺服器比對資料庫中的 session 記錄，若尚未手動撤銷，便會判定為合法請求並簽發新的 10 分鐘 JWT。心跳 API 本來是為了維持使用者正常在線，但在攻擊場景下，長效憑證成了攻擊者源源不絕取得合法短效 JWT 的管道。

4.傳統 IP 或設備特徵比對的極限：許多架構會嘗試在換發 token 時比對客戶端 IP 或 User-Agent。然而攻擊者要偽造 User-Agent 就跟吃飯喝水一樣毫無難度；若比對 IP，使用者在日常生活中切換 Wi-Fi 與行動網路，或是網路不穩時就會經常被誤判踢出，工程師被狗幹一頓之後，實務上通常只能放寬限制，把正常使用者跟攻擊者一起放行。

短效 JWT 搭配長效 cookie 的設計，在沒有硬體綁定時，頂多只能限制單次外洩的存取時間，卻擋不住長效憑證被複製後的無限續期。

DBSC 的關鍵效益在於將 /RefreshEndpoint 換票流程綁定在硬體 TPM 或 Secure Enclave 的私鑰簽章上。攻擊者即便複製了長效與短效 cookie，在自己的機器上也無法通過 refresh 的簽章驗證，10 分鐘後存取權限便徹底失效。

設計上的兩組 cookie

長效 cookie 只用來換發短效 cookie，內容是 example_sessions 的不透明 ID，伺服器每次 refresh 都會查表確認未撤銷且已綁定。短效 cookie 是 JWT，用於心跳與一般 API；一般業務 API 只驗 JWT 簽章與到期時間，不會每次請求都查詢資料庫（心跳 API 的查表取捨見下方說明）。

StartSession 與 refresh 端點

登入回應加上 Secure-Session-Registration 標頭。/StartSession 驗證 JWT 簽章後，在 example_sessions 寫入三個欄位：bind_id（random_bytes(16) 產生的 hex 字串，唯一索引）、member_id（從 JWT 的 sub 取得，不接受客戶端傳入）、public_key（請求中的 JWK，存成 JSON 文字）。

challenge 存在 example_challenges 資料表（欄位：challenge、bind_id、expires_at），驗證成功或過期後立即刪除。

refresh 端點依 Chrome 流程先回 403 與 Secure-Session-Challenge，驗證 Secure-Session-Response 通過後才發新的短效 cookie。challenge 要一次性且有時效，避免被重放。

心跳 API 不需要加標頭，但會碰到 refresh

許多系統會設計定時發送的「心跳 API」（Heartbeat），每隔一兩分鐘由前端自動向後端發出請求，用來確認使用者是否在線上、檢查帳號是否被停用或停權，或是順便換發憑證。

導入 DBSC 後，最容易產生的第一個疑問是：心跳 API 每次呼叫，都需要跟硬體晶片要簽名嗎？

答案是不用。心跳 API 本身不需要加上 Secure-Session-Registration 標頭，前端也不需要為每次心跳呼叫特別計算硬體簽章。它就像一般 API 請求一樣，照常帶著 Cookie 送出即可。唯一的變化是：當心跳請求落在保護範圍內，且所需的短效 Cookie 缺少或到期時，瀏覽器會在底層暫停心跳請求，先呼叫 DBSC 續期端點換取新 Cookie 後再送出；瀏覽器也可能在到期前提前續期。因此，心跳偶爾會等到換證完成才抵達後端。

這也帶來另一個架構上的疑問：原本的系統通常就有「JWT 換證」流程，現在加上「DBSC 換證」，兩者是不是重複做工了？

事實上，依 RFC 7519，JWT 本身只是一種承載資料的格式，並不具備自動換證能力。平常大家口中的「JWT 換證」，是應用程式另外設計的機制（例如依 RFC 6749 第 6 節 的 OAuth 2.0 規則，拿長效 refresh token 換取新的 access token）。這兩套機制的分工完全不同：

在這類架構中，最乾淨的做法是將前兩者整合成同一次換證，不必在系統裡維持兩套獨立的換發流程：

1. 統一憑證儲存：直接將承載短效 JWT 的 Cookie 列入 DBSC 的 credentials 清單，交由瀏覽器統一管理。
2. 集中由 DBSC 發動續期：當 Cookie 需要換發時，由瀏覽器主動呼叫 DBSC 續期端點，後端同時驗證硬體晶片簽章、帳號狀態與停權紀錄。
3. 驗證通過即發新 JWT：後端確認硬體簽章合法後，直接呼叫原本產製 JWT 的函式，並透過 Set-Cookie 將新的短效 JWT 寫回瀏覽器。若無變更 DBSC 設定，回傳空內容的 HTTP 200 即可。
4. 原請求順暢送出：瀏覽器取得新 Cookie 後，剛才被暫停的心跳或業務請求就會自動帶上新憑證送出，後端 API 依然只需單純檢查 JWT 的簽章與效期。

在整合這兩套機制時，需要特別注意以下實務細節：

• Cookie 不應晚於 JWT 到期：兩者的有效期限不必完全一致，重點是 Cookie 不能比 JWT 更晚到期。DBSC 只會依 Cookie 是否缺少、過期或需要提前續期來發動 refresh，不會主動解析網站 JWT 內部的到期欄位（可對照 DBSC 草案的 Cookie 憑證判定流程）。如果 Cookie 設為兩小時才到期，JWT 卻在十分鐘就失效，瀏覽器會誤以為憑證依然有效而不發動換證，導致一般 API 收到過期 JWT 直接拒絕請求（回傳 401 錯誤）。
• 前端定時換證程式可以簡化：原本前端 JavaScript 寫的定時換證計時器，或是「收到 401 就重試換證」的攔截邏輯，只有在「這次登入已成功完成 DBSC 綁定」的情況下，才能交由瀏覽器處理，同時避免兩邊同時換證造成衝突；因為瀏覽器支援 DBSC 並不代表每次登入都一定註冊成功，未註冊或舊版瀏覽器仍需保留原有機制。
• 心跳 API 是否保留取決於業務目的：如果心跳唯一的用途就是「防止 Token 過期」，那麼整合進 DBSC 換證後就可以移除。但如果心跳還負責統計在線人數、檢查帳號停權狀態，大部分使用者都使用不支援 DBSC 的瀏覽器，那就依然有保留的必要。
• 背景換證不等於真人正在操作：DBSC 是由瀏覽器在背景自動發動續期，即使使用者暫時離開電腦，瀏覽器也可能自動完成換證。因此，系統不能只要看到 DBSC 換證成功，就直接把使用者的閒置登出時間往後重設，否則會破壞原本的閒置逾時安全防護。

心跳與撤銷的取捨

本案例的決定：

• 心跳 API 每次都查 example_sessions，確認 revoked_at 為 NULL 且 bind_id 尚未撤銷，再更新最後活動時間。
• 查詢使用 bind_id 的唯一索引，每次心跳只多一次主鍵查詢。

這樣拆分的結果是：正常停留在頁面上的使用者，在撤銷後最多一個心跳間隔（預設 60 秒）就會因心跳回傳 401 而被前端導向登出；但若攻擊者繞過前端，直接拿偷來的短效 JWT 呼叫一般業務 API，因為一般 API 仍只驗 JWT 簽章與到期時間、不查資料表，這組請求要等到該張短效 cookie 自然到期（最長 10 分鐘）才會真正失效，並在到期後因無法通過 refresh 續期而徹底斷線。

如果要求所有業務 API 在撤銷當下立刻失效，就要改成每次請求都查表（或維護撤銷清單快取），這會增加資料庫與快取負載。

登出與撤銷

登出時把該筆 example_sessions 的 revoked_at 欄位（UPDATE example_sessions SET revoked_at = now() WHERE bind_id = ?），回應中以 Set-Cookie: ...; Max-Age=0 清除長效與短效兩種 cookie。

即使長效 cookie 已不在資料庫中，仍要回傳清除的回應，不能回錯誤。寫入撤銷紀錄後，refresh 一定失敗，已採每次查表的心跳 API 也會立即回 401。只清 cookie 而不更新資料表，偷走的長效副本仍能換發新的短效 cookie，這點要在實作時逐一確認。

沒有 DBSC 時，本來的防禦擋不住什麼

這個案例把 session 全數集中在 VM 內的本機 Redis，並配合短 TTL 與定時更換 session ID，看似在伺服器端兼顧了效能與管理彈性。然而在缺乏 DBSC 硬體綁定時，依然有無法防禦的漏洞。

問題同樣在使用者裝置上的惡意程式，利用系統權限解密瀏覽器的 Cookie 檔案，取得當前有效的 PHPSESSID 字串。當其他挾帶此 ID 的請求送往後端時，Redis 只負責根據 key 查出序列化資料，確認該 session 存在且未過期就直接載入。程式完全無法辨識這個 HTTP 請求究竟是來自原使用者的電腦，還是遠端的攻擊者。

傳統安全建議依靠每 30 分鐘執行一次 session_regenerate_id 來降低外洩風險。但如果被害者電腦常駐著惡意程式，每次換發後產生的新 PHPSESSID 依然會被即時擷取；攻擊者只要保持連線，就能在原本的使用者 session 被銷毀前持續操作。

當本機 Redis 發生 OOM 當機或重新啟動，系統退回其他 fallback 機制時，若殘留著尚未清除的舊 session 檔案，原本已被使用者登出或過期的 session 可能重新生效。攻擊者手中持有的舊 cookie 反而可能再次被伺服器接受。

這種把 session 放在 Redis 的設計，主要是提升伺服器端的讀寫效能與集中快取能力，或是方便日後改成外部 Redis 服務方便水平擴展。但安全性上無法防禦使用者裝置上 cookie 遭複製的問題。無論 Redis 的查詢速度有多快，就只是傻傻的驗證字串。

導入 DBSC 後，即使攻擊者拿到有效的 PHPSESSID，在短效期滿時，也無法透過缺乏本機硬體私鑰的機器向 refresh 端點換發新憑證，真正讓遭竊的 session 失去續期能力。

導入 DBSC 時的注意事項

假設登出、撤銷與故障 fallback 功能都非常完善，在這種本機 Redis session 的架構下導入 DBSC，仍有幾件事要特別處理。

1. 綁定資料要獨立存放，例如 example_binding:{bind_id}，不要掛在 example_session:{session_id} 底下。若綁定跟著 session 走，Redis 資料遺失或 session ID 更換時，綁定也會一起消失。
2. Redis 不可用時，refresh 應直接回錯誤，讓使用者重新登入。否則 DBSC 的 refresh 若讀到本機檔案，就可能在 Redis 故障時替本該失效的舊 session 續期。
3. Secure-Session-Challenge 必須一次性，並且存在 Redis，例如 SET example_challenge:{bind_id} ... EX 30 搭配 GETDEL（以 bind_id 為索引儲存挑戰碼，設定 30 秒後過期，取出時立即刪除）。若 challenge 存在 PHP worker 的記憶體，同一個 refresh 請求落到另一個 worker 就會驗證失敗，即使只有一台 VM 也一樣。
4. 同一會員可能有多組綁定（例如同一帳號分別在桌上型電腦與筆電登入，兩台裝置各自建立一組綁定），撤銷必須能針對單一綁定 ID，而不是只能全部撤銷或完全不撤銷。
5. 若有多套獨立登入流程（例如同一個人是買家與賣家身分時，要分開登入不同帳號），不同驗證流程的 Cookie 名稱、Path 與 DBSC 設計建議要分開，以免混淆。
6. 測試要包含 Redis 重啟(因資源不足、服務重啟或 VM 重開而暫時中斷)的情境、同一會員在兩台電腦各自註冊，以及撤銷其中一組綁定後，另一組仍能正常使用。

導入 DBSC 前需要的反查索引

DBSC 的撤銷要能做到會員層級：會員被停權或要求全部登出時，要找出他所有的 session 與綁定，全部撤銷。在 Redis 架構下，這需要先設計一個反查索引，常見有兩種做法：

• 會員索引：登入時把 session ID 加入 example_sessions:{account_id} 這個 Redis Set。session_regenerate_id 時要同時移除舊 ID、加入新 ID；destroy() 時也要移除。Set 的 TTL 要和最長的 session 一致，否則會累積過期的 ID。撤銷時讀出整個 Set，逐一刪除 example_session:{session_id}。
• 撤銷清單：不維護索引，改在每次 read() 時檢查 example_revoked:{session_id} 是否存在，存在就視為未登入。這種做法實作簡單，但每個請求多一次 Redis 讀取，而且撤銷的是 session ID，仍要先知道會員有哪些 ID，才能寫入撤銷清單。

兩種做法都要把 DBSC 的綁定納入同一個索引。每筆綁定以 example_binding:{bind_id} 儲存，內容包含會員 ID 與公鑰；會員索引再列出該會員的 bind_id 清單。撤銷時先處理綁定，因為 refresh 驗證的是綁定，綁定被撤銷後，即使 session 還在，也無法再換發短效 cookie。

選哪一種，取決於每次請求能否多承擔一次 Redis 讀取，以及撤銷要多快生效。

多台合法裝置的自動化請求不在 DBSC 防護範圍內

聽到會員帳號登入時，還得根據硬體層級做簽章驗證，也許有人會想說拿來做防堵自動化程式的濫用？例如同一個帳號在多台電腦上同時登入，要搶只有一件的限量商品、搶選課、搶門票，只要任何一台成功進入，就能大大增加搶購成功率。

同一個帳號可以在多台電腦正常登入，每台電腦都建立自己的 DBSC 綁定，每一個 session 都是合法登入、合法簽章，網站程式無法判斷這些請求不正常。DBSC 不能保持裝置唯一性，頂多能保證使用的裝置是真的電腦，而不是一些無法驗證 DBSC 的自動化虛擬設備。更何況現在手機瀏覽器也不支援 DBSC，攻擊者可以用手機或模擬器繞過硬體簽章。

這類問題需要在業務層處理，例如 rate limit、每帳號配額，DBSC 主要的應用場景不是拿來幹這種事。

如果改用外部 Redis 服務會有什麼差異

本案例剛剛的討論都假設 Redis 與 PHP 在同一台 VM 上，若系統已經需要依流量動態加開或關閉機器，並改用雲端託管的 Redis，例如 AWS ElastiCache 或 Upstash，有幾件事會改變。

優點：

• 多台 PHP 主機可以共用同一份 session 與 DBSC 綁定資料，之後要水平擴展時，不必再重新設計所有身分驗證機制。
• 持久化、備援與自動容錯移轉通常由服務商處理，不必自己管理 AOF、RDB 快照與主從切換。
• Redis 重啟或 VM 重開，不再直接清空所有登入狀態的 session。

缺點與問題：

• 延遲：每次 read() 都要跨網路，延遲從接近零變成數毫秒到數十毫秒。要是驗證途中使用者做了其他操作，可能會操作失敗，使用者會納悶為什麼常常莫名被登出或是操作失敗。
• 網路故障的模式變多：除了 Redis 本身故障，還有網路分割、DNS 解析失敗、連線池耗盡與 TLS 握手逾時。
• 各家雲端 Redis 提供的連線方式有差異，例如有些提供 REST 模式，適合 serverless 或短連線，但每次呼叫都是一個 HTTP 請求，成本與延遲都較高，但整合方便。TCP 模式則需要先確認伺服器或系統架構支援對應的設定。
• 成本問題，有些以 instance 規格計費(例如 Amazon ElastiCache 的隨需節點)，有些則是 serverless 架構，以請求數或容量計費。當使用者人數多、redis session 讀寫頻繁時，用量計價可能突破天際。反查索引與撤銷清單也會讓這個成本乘上好幾倍，需要在每個請求的讀取次數上精打細算。
• 故障時的 fail closed：外部 Redis 不可用時，退回本機檔案的 fallback 不適合直接沿用，因為多台水平擴展主機的本機檔案彼此不同步。refresh 與撤銷要直接回錯，一般讀取則要決定是要求重新登入，還是讓使用者看到維護頁面。甚至最搞笑的是以為挑了幾間可以當備援，但是他們上游都是同一個雲端供應商，大家一起掛掉。
• 持久化與資料一致性：託管服務的 failover 可能在主從切換時丟失最近寫入的資料，剛完成登出或撤銷的寫入可能還原。這對撤銷是實質風險，需要確認服務的同步複寫設定。

改用外部 Redis 後，程式本身綁定 ID 的管理與反查索引的設計不變，但要把每次請求的讀取次數($$$)與 fail closed 的行為列為上線前的必要測試。

JWT 換證已由套件包好，還方便加入 DBSC 嗎？

在採用 Next.js 與 PHP 後端的架構中，許多系統會直接使用現成的認證套件處理 JWT 登入與換證機制。在日常開發中，換證往往只需要呼叫幾行人家封裝好的東西（例如 Laravel JWT Auth 的 refresh()），套件就會產生新 Token 並讓目前的 Token 失效。

這就是最可怕的事情，站在巨人的肩膀上可以很快爬得更高遠，但一旦需求超出套件原本的設計，工程師就可能陷入「套件封裝得太完整，無法插入自訂邏輯」的困境。

接入 DBSC 是不是在這些函式多加幾個參數就好？答案是沒辦法直接套用。套件把細節封裝得越完整，往往代表內部流程越固定。DBSC 要求瀏覽器在背景出示硬體簽章來換取新憑證，若現成套件不允許拆解換證流程，我們就很難把硬體驗證插進去。

從非工程人員的角度來看，既有套件無法直接套用 DBSC 的原因主要有四個：

1. 換證時的驗證對象不同：有些套件要求提供原本的 Token；如果 Cookie 已被清除，就可能無法直接沿用換證函式（例如 JWT Auth 的套件設定 雖然有獨立的續期期限，讓過期後的 JWT 仍可能換證，但依然需要提交原 Token）。反觀 DBSC 的換證是由瀏覽器底層發起，驗證的是實體裝置用私鑰簽出的硬體證明（DBSC proof），伺服器必須先完成硬體簽章驗證並查回登入紀錄，再透過套件支援的方式核發新憑證。
2. 無法透過在 Token 內多加欄位解決：有些團隊會嘗試在原本的 JWT 內容中加入自訂標籤（例如 is_device_bound: true 或綁定 ID）。但這種做法完全無法提供防護。因為一旦 Token 被惡意程式竊取，裡面的標籤也會原封不動被複製到攻擊者的電腦上。DBSC 的安全性來自於每次換證時，瀏覽器都必須現場使用硬體晶片簽章，而不是 Token 內部寫了哪些宣告文字。
3. 前端儲存機制必須改用受管理的 Cookie：很多前端套件習慣把 Token 存放在瀏覽器的 localStorage，再透過 JavaScript 於請求標頭夾帶 Authorization: Bearer 傳送。然而 DBSC 是瀏覽器層級的標準，負責管理設定範圍內的 Cookie（規格也支援同站範圍，可參考 DBSC 草案）。如果系統原本完全依賴 localStorage，DBSC 就無法介入管理，必須改為受管理的 Cookie，或由同源的 BFF（Backend for Frontend）持有上游 Token，讓瀏覽器只使用受 DBSC 保護的 Cookie。
4. 如果 Token 是由外部服務核發（例如交給 Auth0、Firebase Auth 等雲端認證平台，或是串接 Google、LINE API 的授權 Token），換發權限不在本站伺服器手上，那些外部服務也不會鳥我們自訂的 DBSC proof。網站能做的只有在本地先驗證裝置綁定與代理層的狀態，確認合法後，再由後端使用仍有效的上游 refresh token 向外部服務換證。

因此，這些使用了現成 framework 拼裝起來的系統，能否順利接入 DBSC，不是看原本的換證程式寫起來有幾行，花多少時間，就能輕易評估製作工時。而是取決於套件是否開放以下關鍵控制點：

如果套件有提供中介層（middleware）、事件攔截或自訂 callback，開發人員可以保留套件原本產製 Token 的能力，先完成硬體簽章驗證，再呼叫套件核發新憑證。反之，如果套件是完全封閉的黑盒子，無法插入自訂驗證邏輯，除了必須另外建立獨立的註冊與續期端點，原本不檢查 DBSC 的換證入口，也必須能關閉或加上限制，否則攻擊者仍可透過舊入口繞過裝置綁定。

特殊之處 1：視覺化反饋打破「完全無感」的迷思

DBSC 官方標準非常自豪於「使用者完全無感，瀏覽器底層會自動換票」。但回到現實職場，如果你花了三天三夜搞定 DBSC，上線後使用者、測試員甚至老闆問你：「我們到底有沒有走到這個硬體安全防護？」，你回一句「一切都在空氣中默默完成了，你看不到是正常的」，大概率會被當作在摸魚。

在 Next.js 架構下，可以讓瀏覽器在背景續期，同時由應用程式呈現驗證狀態：

1. 後端狀態回傳：在身分查詢的回應中附帶登入、綁定與憑證有效性等資訊。
2. 登入後視覺提示：完成身分驗證後，先確認身分查詢成功，再依綁定狀態與憑證有效性顯示提示。
3. 導覽列與設定頁徽章：在導覽列顯示裝置綁定狀態，並在帳號安全設定頁說明憑證有效性與續期機制。徽章是應用程式的狀態提示，不能代替硬體驗證或完整的續期測試。

以下欄位名稱與結構僅供示意，registered 代表伺服器已記錄公鑰綁定，credential_valid 代表本次請求的短效憑證有效：

{
  "authenticated": true,
  "account": { "display_name": "範例使用者" },
  "device_session": {
    "registered": true,
    "credential_valid": true
  }
}

前端 JavaScript 依然絕對不要自己去寫 WebCrypto 產金鑰或發簽章！所有的金鑰生成與換票依然純靠 Chromium 的底層網路棧接管。前端的角色僅是「接收狀態並呈現」，不要越俎代庖。

特殊之處 2：反向代理與 Web 伺服器的「標頭吃案」

DBSC 的註冊與續期請求由瀏覽器送往 Laravel 後端。若部署環境前方有 CDN 或反向代理，應確認 DBSC 所需的請求標頭能傳到 PHP，回應中的 DBSC 標頭與 Set-Cookie 也能正常回到瀏覽器。

DBSC 依賴非標準的 HTTP 標頭：

• 瀏覽器換票送出的 Sec-Secure-Session-Id
• 包含 TPM 簽章 JWT 的 Secure-Session-Response

很多預設的 Apache / Nginx 規則，或是一些奇怪的管理介面，會認為這不是標準標頭而直接將其濾除(吞掉)。導致後端 $_SERVER 永遠抓不到簽章，Chrome 狂噴失敗卻找不到原因。必須在設定中明確宣告透傳：

RewriteEngine On
RewriteCond %{HTTP:Sec-Secure-Session-Id} ^(.+)$
RewriteRule .* - [E=HTTP_SEC_SECURE_SESSION_ID:%1]
RewriteCond %{HTTP:Secure-Session-Response} ^(.+)$
RewriteRule .* - [E=HTTP_SECURE_SESSION_RESPONSE:%1]

地雷：SPA 並行請求的「Session 覆蓋風暴」

在前後端分離的單頁應用（SPA）中，使用者一打開頁面，前端往往會在同一時間發出多個 API 請求（例如同時查詢登入身分與拉取其他業務資料）；如果剛好遇到憑證到期，瀏覽器也會在背景同步送出 DBSC 的註冊或換證請求。這些請求全都共用同一個使用者的 Session，卻不會在同一毫秒結束。

許多 framework 或自訂的 Session 處理器，預設不會在請求期間鎖定 session，且讀寫方式是「開頭整包讀入記憶體、跑完業務邏輯、結尾整包覆蓋寫回」（不論 session 底層是存檔案、資料庫還是 Redis 都一樣）。當多個請求同時進行時，就會發生「慢結束的舊資料，把先結束的新資料蓋掉」的 race condition：

1. 請求 A（處理較慢的一般 API）先抵達後端，把當下的舊 Session 資料讀進記憶體（此時裡面還沒有新的短效憑證）。
2. 請求 B（瀏覽器的 DBSC 換證請求）稍微晚一點進來，但處理很快，驗證通過後就把新核發的短效憑證雜湊與下次挑戰碼寫回 Session 儲存區，率先結束。
3. 請求 A 這時才終於執行完畢，在結束時把自己記憶體裡那份「還沒換證前的舊 Session」整份寫回 Session 儲存區，直接把請求 B 剛存好的新憑證與挑戰碼全部蓋掉。

結果就是：瀏覽器明明已經收到新的短效 Cookie，但伺服器端的紀錄卻被退回舊版，導致下一個 API 請求帶新 Cookie 來時直接被判定驗證失敗。同樣地，如果兩個註冊請求同時進來，也會因為同時讀到「尚未綁定」的狀態而各自寫入不同公鑰，導致綁定資料互相覆蓋損毀。

這種問題無法只靠「寫回前再讀一次最新資料做欄位合併」來解決，因為那依然擋不住兩個請求在剛進來時同時讀到未綁定的舊狀態。只要仍把 DBSC 狀態放在同一個 Session 內，正確的做法是在後端中介層讀取 Session 資料之前，就先對該 Session ID 加上互斥鎖（例如本機檔案用 flock(LOCK_EX)，Redis 或資料庫則搭配分散式鎖或框架的 Session Blocking 機制），將讀取、路由驗證、狀態更新與寫回全部包在鎖定範圍內，最後於 finally 區塊確保釋放鎖定，讓同一個 Session 的並行請求依序排隊執行；或者直接將 DBSC 狀態從整包讀寫的 Session 拆出來獨立儲存，避免被一般 API 的寫回動作蓋掉。

地雷：Chrome 主動換票（Proactive Refresh）與在途請求誤擋

根據 Chromium 的底層實作（session_service_impl.cc），Chrome 不會等到短效 Cookie 真正過期的那一刻才去換證，而是會在接近到期前就提前在背景發動主動續期（Proactive Refresh）。

這會帶來一個時間差問題：當瀏覽器在背景換發新憑證的那一瞬間，前端頁面可能正好在幾毫秒前發出了其他 API 請求，而且這些請求已經在網路上傳輸中（在途請求，in-flight requests）。這些已經發出去的請求，身上帶的還是換證前的「上一張舊 Cookie」。如果後端在換證成功的瞬間就立刻把舊憑證抹除，晚幾毫秒才抵達後端的在途請求就會被判定無效（回傳 HTTP 401），導致前端畫面無故跳出錯誤。

為了避免誤擋這些在途請求，後端需要為剛換下來的上一代憑證保留一小段寬限期（Grace Period，例如 120 秒）。但在實作寬限期時，必須避開一個常見的安全漏洞：

• 錯誤寫法：在換證時無條件將舊憑證的寬限時間設為「現在時間加 120 秒」（例如 $request->session()->put('example_previous_grant_expires', time() + 120)）。
• 風險原因：假設使用者離開電腦 30 分鐘，原本的短效憑證早就已經過期。當他回到電腦前觸發換證時，如果程式不檢查舊憑證原本是否還有效，就一律給它延壽 120 秒，等於讓一張已經失效半小時的舊憑證重新復活兩分鐘。若這張舊 Cookie 先前曾外洩，攻擊者就能趁這兩分鐘空檔再次呼叫 API。

正確的寬限期邏輯必須先確認舊憑證在換證當下是否還沒過期（$currentExpiresAt > time()）：

1. 只有原本還在有效期限內的舊憑證，才允許進入寬限期，且寬限截止時間應取「原到期時間」與「現在時間加 120 秒」兩者中較早的時間（min(原到期時間, 現在 + 120秒)）。
2. 如果換證當下舊憑證本來就已經過期，就必須直接銷毀，不能給予任何寬限。

地雷 3：舊 Session 升級時接受未驗證的 Cookie

當系統把 DBSC 的短效憑證機制更新上線時，網站上通常還有一批「更新前就已經登入」的線上使用者。這些舊 Session 雖然可能已經有綁定編號（example_binding_id），但伺服器端還沒有新版本要求的短效憑證雜湊紀錄（example_grant_hash）。

為了不讓這些線上使用者被強制登出，開發者很容易直覺寫出一段「自動補登」的相容程式，只要看到舊 Session 還沒記錄短效憑證，就把瀏覽器這次請求帶來的 Cookie 直接登記為有效憑證：

// 錯誤範例：未經硬體驗證就直接信任客戶端送來的 Cookie
if ($session->has('example_binding_id') && !$session->has('example_grant_hash')) {
    if (!empty($cookie)) {
        // 客戶端有送 example_grant，就直接補記為有效憑證
        $session->put('example_grant_hash', hash('sha256', $cookie));
        $session->put('example_grant_expires', time() + 600);
        $isValid = true;
    }
}

這段程式碼會造成嚴重的驗證繞過漏洞：因為 Cookie 是由客戶端傳來的資料，在未經驗證前，伺服器無法確認它的真偽。如果攻擊者竊取了受害者的舊 Session Cookie，他根本不需要受害者電腦的硬體私鑰，只要在發送請求時自己隨便捏造一串 example_grant=attacker_random_token，伺服器就會直接把它登記為合法憑證，讓攻擊者取得 10 分鐘的存取權限。

正確的做法，簡單來說就是讓使用者全部重新登入，不能直接信任客戶端提供的任何未驗證 Cookie 值。面對伺服器端這批缺少短效憑證紀錄的舊 Session，應一律視為尚未通過驗證，先通通清掉並回傳 HTTP 401（需要續期）。這會要求瀏覽器走正規的續期流程，以本機硬體安全晶片向續期端點發送挑戰簽章；唯有通過硬體簽章驗證，伺服器才能核發真正的短效憑證。

網頁版與 LINE 聊天機器人共用後端

一套後端 API 同時給網頁版與 LINE chatbot 使用，網頁版用帳號密碼登入，LINE 內則透過 LIFF 驗證。兩條路徑最後可能都寫進同一個 session 欄位或各自的欄位。

DBSC 只適合網頁版的那一條。LIFF 在 LINE 內建瀏覽器或外部瀏覽器執行，不一定支援 DBSC，即使支援，它的身分來源是 LINE 而不是密碼登入。實作上要把檢查加在「帳密登入的 session 分支」，LIFF 的分支維持原本的驗證，兩條分支用 OR 組合時要小心，不要讓 DBSC 失敗的 session 因為另一條分支而被放行。

網頁版與瀏覽器擴充套件、VS Code 擴充套件

之前的文章把部落格後台搬進 VS Code：修圖、上傳、管理圖片、AI 產生分類與標籤一次搞定介紹過，vscode 套件裡的瀏覽器狀態極不穩定，所以擴充套件不走瀏覽器的 cookie 流程，而是通常帶一把 API Key 或 token 呼叫同一批 API。

這些請求沒有短效 cookie，也無法回應 Secure-Session-Challenge。因此後端的驗證函式必須先判斷請求是帶 API Key 還是靠 session，只有 session 分支才套用 DBSC。如果檢查寫在整個驗證函式的最外層，擴充套件會一次全部失效。

另一個風險是反過來：同一個 API 同時接受 API Key 與 session。DBSC 只保護 session 那條，另一邊的 API Key 只要外洩，攻擊者一樣能拿到相同的權限。網站應用程式這邊還在小心翼翼苦苦的短期驗證，然後攻擊者拿著長效 API key 暢通無阻。

這不是 DBSC 的問題，但導入這些安全玩意後，很容易讓人以為整個系統都已經被安全了，但實際上安全破口還是一堆。

什麼? 你說 API key 要經常輪替? 唉呦，有人會說資訊人員又來找麻煩了，公司系統這麼難用不去優化，整天搞這些有的沒的(下略一萬字)。

網頁版與 Electron 桌面應用程式

Electron 內建的是 Chromium，但 DBSC 是否可用取決於 Electron 版本、是否有設定持久的 session 儲存、以及作業系統的硬體金鑰支援。桌面應用程式也常把登入狀態存進自己的檔案或系統金鑰庫，再以 header 帶 token。這時要決定：

• 桌面應用程式走瀏覽器式的 cookie 登入，並接受它可能無法使用 DBSC 的現實。
• 桌面應用程式改用自己的 token，並由後端對 token 做另一套綁定，例如把 token 與裝置金鑰綁在一起，不依賴 DBSC。

不論選哪一種，後端都要能分辨請求來自哪一種客戶端，而不是用同一個旗標一視同仁。

同一個使用者，不同客戶端要用不同的驗證層

整理起來，常見的客戶端與適合的驗證方式如下：

導入前的檢查清單

1. 列出所有會讓請求通過驗證的路徑，包含 session、API Key、第三方登入。
2. 標出哪些路徑的客戶端是瀏覽器，只對這些路徑加 DBSC 檢查。
3. 檢查函式要有寬鬆模式，沒有綁定的 session 照舊放行。
4. 不要把 DBSC 檢查放在整個驗證函式最外層，應該放在 session 分支內。
5. 保留一個短暫的觀察期，用日誌確認 refresh 真的有成功，再擴大範圍。

最後再次強調，DBSC 解決的是「瀏覽器 session cookie 被幹走」的問題，它不是統一登入層。後端同時服務多種客戶端時，要先決定每種客戶端怎麼證明自己是誰，再決定 DBSC 要套用在哪一條路徑上。

複製 Cookie 貼入外部腳本的做法會直接失效

以往許多搶票軟體或社群貼文爬蟲，為了繞過複雜的登入驗證碼（CAPTCHA），最常見的手法是讓使用者先用真實瀏覽器正常登入，再透過開發者工具複製當前有效的 Session Cookie 值，然後再貼入 Python、Node.js 等各種自製的 CLI 腳本中，在自己的電腦，或是另外準備的雲端伺服器上高效率搶票。

在導入 DBSC 的架構下，效果非常顯著，這類外掛軟體會直接面臨阻礙：

1. 伺服器發給瀏覽器的主要是短效 Cookie（例如 2 到 5 分鐘有效），當外掛腳本把這串短效 Cookie 複製出去使用，幾分鐘後 Cookie 就會失效。
2. 外部腳本若試圖呼叫 refresh 端點取得新 Cookie，伺服器會要求用私鑰簽章證明身分。但私鑰被安全保存在原電腦的 TPM 2.0 晶片或 Secure Enclave 中，外部腳本無法匯出私鑰，因此無法完成換票。
3. 許多搶票團隊習慣將自動程式放在雲端 Linux VPS 或 Docker 容器群多點並發。一旦離開了原本登入的那台實體電腦，這組 Session 幾分鐘內就會失效，這種雲端虛擬化環境還根本無法完成 TPM 這類驗證。

機器人能用 Chrome Headless 偽造標頭繞過嗎？

面對 DBSC，自動化程式是否能輕易偽造請求標頭？實務上有幾種限制與攻防考量：

• 標頭無法以字串偽造：DBSC 的 Secure-Session-Response 標頭並非固定格式的字串，而是包含 TPM 私鑰對伺服器隨機 Challenge 產生的 ECDSA（P-256）硬體數位簽章。沒有硬體私鑰，任何 HTTP 腳本都無法自行產生有效簽章。
• 被迫啟動完整瀏覽器的資源成本：機器人若要合法簽章，就必須直接操控本機上的完整 Chromium（例如透過 Puppeteer 或 Selenium）。過去一台電腦可以併發執行上千個輕量 Python 爬蟲協程，改為執行完整的瀏覽器實體後，記憶體與 CPU 成本會大幅增加，極大壓低了黃牛單機的併發規模。
• 雲端農場的環境限制：主流的雲端 Linux 伺服器與 Docker 容器通常缺乏實體 TPM 2.0 模組，且 Linux 版 Chrome 尚未支援 DBSC 的 TPM 整合。這讓搶票腳本無法在廉價的雲端 Linux VM 上大批量開啟 Headless Chrome 刷票。
• 機器人目前的逃生門（降級攻擊）：DBSC 目前最大的防禦缺口在於平台覆蓋率。因為實際上大部分人使用的 iOS Safari、Android 與 Firefox 尚未支援 DBSC，若購票網站採取「寬鬆模式」（有支援才綁定，沒支援就退回一般長效 Cookie），搶票腳本只需把 User-Agent 偽造成 iPhone Safari 或 Firefox，就能迫使伺服器直接核發傳統長效 Cookie，進而繞過整個 DBSC 防護。

若購票網站想發揮 DBSC 的防禦效果，要把「是否已完成 DBSC 綁定」當成風險分流的門檻：所有未完成 DBSC 綁定的連線（不論是真正的手機 Safari、Firefox，還是故意偽裝 UA 的腳本），進入搶票或下單等高風險流程時，一律進嚴格限流或補跳額外的人機驗證；只有確實通過 DBSC 硬體綁定的 Session，才維持一般順暢通道。

Google 對 DBSC 的三項後續展望

根據 Google 安全團隊官方發布的部落格，DBSC 在核心規格逐步成熟後，正朝向三個方向延伸：

1.聯合身分驗證（SSO）的安全延伸：在現代企業環境中，單一登入（SSO）已非常普及。多數系統由身分提供者（IdP，如 Google Workspace 或 Okta）登入後跳轉至信賴方（RP）服務。Google 正在擴展 DBSC 協定以支援跨網域綁定，確保 RP 端的會話能延續 IdP 登入時綁定的那把原始裝置金鑰，建構一條不間斷的端對端信任鏈。

2.整合既有受信任金鑰的進階註冊：目前 DBSC 是在登入時由瀏覽器調用 TPM 動態生成全新金鑰。但在特定高安全性環境中，Google 正在開發允許 DBSC 直接綁定至裝置上預先存在的受信任金鑰材料（例如企業的 mTLS 用戶端憑證，或是 FIDO / YubiKey 這種硬體安全金鑰），將 Session 註冊與更嚴格的硬體管控直接整合。

3.拓展至無專屬硬體的設備：目前 DBSC 把 Linux 系統、舊電腦、iPhone、iPad 與其他行動裝置通通排除在外了，因為功能高度仰賴 Windows TPM 2.0 與 macOS Secure Enclave。Google 表示正在積極探索基於軟體實作的安全金鑰機制，讓缺乏專用安全晶片的設備也能獲得相似機制的保護。

Vercel 的第一線實踐：Polyfill 嘗試與 CLI 上的 DPoP

率先在線上平台實裝 DBSC 的 Vercel CTO Malte Ubl 則提出了 開發者生態系的現實觀察與補充手段：

瀏覽器普及率與 Polyfill 過渡方案：現階段 DBSC 的原生支援仍主要集中在 Windows 與 macOS 的部分桌面版瀏覽器，為了兼顧其他環境，Vercel 正在為非支援瀏覽器開發基於 JS polyfill。但這是過渡期的相容手段，因為純前端 Polyfill 無法獲得硬體級防匯出的安全保證，他們也期盼 Safari 與 Firefox 未來能正式跟進原生實作。

終端機與桌面應用程式改用 DPoP：DBSC 是針對瀏覽器設計的標準，但人類會用瀏覽器上 Vercel，可能只有上去查帳單或看用量報表而已，日常開發過程使用的 vercel login 等 CLI 同樣面臨本機 Token 被木馬整盤端走的風險。

Vercel 選擇在自家 CLI 工具中導入 DPoP（Demonstrating Proof-of-Possession，RFC 9449）。DPoP 的概念與 DBSC 類似，都是透過非對稱金鑰簽發證明來綁定 Token，但它的最大優勢在於不依賴任何瀏覽器廠商支援，在終端機應用與一般應用程式中推行更為直接。