共用網頁快取會否把一位顧客的私人頁面交給另一人？

先按回應分類，再選標頭

小企業為網站加入內容傳遞網絡以加快速度，之後才發現同一網址會向不同顧客返回不同內容。人人看到相同的產品照片通常可共用快取；帳戶頁、訂單詳情、發票 PDF、按顧客權限篩選的搜尋結果，以及載有個人資料的 API 回應，風險完全不同。先建立路由清單，記錄方法、回應類型、內容會否因用戶或租戶而變、是否含敏感資料。成功頁面以外，跳轉、錯誤訊息及下載檔亦要包括，因為重設密碼的回應或失敗訊息，同樣可能帶有私人內容。快取政策應根據伺服器實際送出的回應，而非只看開發人員清單中的網址樣式。

若敏感回應不應被符合標準的 HTTP 快取儲存，OWASP 建議使用 `Cache-Control: no-store`。若個人化但不敏感的回應可留在該顧客的瀏覽器，卻不能進入共用快取，`private` 可表達這條界線；有即時更新需要時再要求重新驗證。`no-cache` 名稱容易誤導，它容許儲存，只要求重用前向來源伺服器核實。MDN 亦提醒，回應中有 Cookie 並不會自動使內容變成私人。真正的業務判斷是這條路由可否在本機保存資料，而非把所有看似安全的指令堆成一長串標頭。選擇較嚴格做法前，亦應考慮返回上一頁的體驗和保密要求。

追查回應可能停留的每一層

一個請求在到達資料庫前，可能經過瀏覽器 HTTP 快取、service worker、內容傳遞網絡、反向代理及應用程式快取。各層不一定遵守相同規則。`no-store` 控制符合標準的 HTTP 快取，但 OWASP 指出，service worker 使用的瀏覽器 Cache API 不會遵從 HTTP 快取標頭；程式須明確排除敏感回應，並清理已有項目。資料庫或 Redis 快取亦須以相關租戶和資源分開索引鍵，命中快取時仍要執行存取檢查。記下每層由誰管理、哪些設定可覆蓋來源伺服器。應用程式送出安全標頭，仍可能被 CDN 強制快取路徑或副檔名的規則破壞。

應主動列出哪些路由真的可以共用，而不是凡回傳 HTTP 200 就交給快取。公開說明頁或帶版本號的圖片，可有明確共用時限。顧客發票即使以 `.pdf` 結尾，仍須採限制政策；按人返回的 API 資料亦不會因為使用 GET 就變成公開。若原本公開的頁面因登入狀態加入問候語或會員價格，便不再對所有訪客相同；要把私人片段移出共用回應，或重新設計快取界線。語言、壓縮方式等不涉及授權的呈現差異，可以靠快取索引鍵或 `Vary` 處理；但這些方法不能代替個人頁面的權限控制。

用帳戶頁面測試整條路徑

假設零售商網站前面有 CDN。顧客登入後，`/account/orders` 會返回其姓名及訂單。團隊把此回應列為敏感內容，由來源伺服器送出 `Cache-Control: no-store`，再檢查經 CDN 到達瀏覽器的實際回應，而不只測試內部伺服器。甲測試帳戶開啟頁面；乙帳戶在另一個瀏覽器設定檔要求相同網址。乙只能看到自己的訂單。員工再測 JSON 端點、發票下載、登入後跳轉及錯誤頁，檢查回應標頭與 CDN 快取狀態。測試應使用虛構紀錄，避免把真實顧客資料寫入除錯日誌。

若首次測試發現舊帳戶回應曾被儲存，只為將來回應加入 `no-store` 並不能消除快取內的既有物件；OWASP 明確建議在改變路由政策時清除先前儲存項目。負責人找出受影響的索引鍵或路由群組，透過快取管理方清除，再以甲乙兩個帳戶重測；亦要檢查 service worker 或應用程式快取有沒有保留副本。若可能曾經外洩，應啟動企業事故處理程序；新標頭測試成功並不能證明過去沒有影響。發佈紀錄應保存路由政策變更、清除證據，以及跨帳戶測試結果。

把風險轉成上線前檢查

實用的驗收矩陣，可按公開、個人化及敏感回應分列，再按來源伺服器、CDN、瀏覽器及應用程式快取分欄。每條路由記錄實際送達的標頭、共用快取有否儲存、轉換帳戶後會否看到舊內容，以及登出或更改權限後可讀內容有否改變。除正常網址外，也試在登入路由後加上像 `.css` 的靜態檔案字尾；OWASP 提醒，動態網址若被偽裝成檔案，可能造成快取欺騙。預期應拒絕畸形路由，而非以看似可快取的名稱返回敏感頁。這些測試應用虛構帳戶進行；掃描器看到一個標頭，不等於正式網站已安全。

快取政策要納入交付流程。新的 CDN 規則、框架更新、API 端點，或價格個人化方式改變，都可能改變路由含義。要求負責人為新回應分類，並在上線前重做相關雙帳戶測試。事前準備按範圍清除特定索引鍵的方法，發現錯誤時毋須把整站公開圖片一併清掉。除了程式碼，還要檢查邊緣節點實際設定。如此，快取控制成為看得見的產品決定：哪些地方需要速度、哪些地方容許本機儲存、哪些地方的保密要求必須避免儲存。

302 跳轉及 404 回應亦要有政策。登入後跳轉的目的地可能透露帳戶狀態；錯誤頁可能包含顧客姓名或資源名稱。檢查 CDN 會否為這些狀態碼套用預設保存時間，框架又會否只對成功的 HTML 頁加上 `Cache-Control`。即使 API 回傳空白內容，狀態碼和標頭仍可能洩露私人狀態。把這些較不顯眼的回應列入清單，可避免只保護主要帳戶頁，卻讓周邊流程被較寬鬆規則儲存。政策應寫到每種回應，並檢視外部用戶實際收到的內容。

除了新登入，亦要在權限變動後測試界線。員工可能已失去某客戶檔案的權限，但舊應用程式快取仍持有內容；顧客亦可能在同一裝置切換兩個企業檔案。預期行為是每次返回快取內容前，都按目前身分和權限範圍重新核准。蒐集足以分辨問題在來源、邊緣或客戶端程式的證據即可，不必為除錯把整個私人頁面寫進日誌。若快取命中時略過授權，單純收緊 HTTP 標頭未必能修好應用程式快取。要修復實際存取路徑，並在出錯的一層重測。

公開資產仍需要速度。若圖片確實對所有人相同，而且內容更新時網址會改變，帶版本號的圖片可繼續放在共用快取，同時保護私人頁面。不要因一條帳戶路由敏感便關掉全站快取；應精確分類，也為公開內容訂明政策。這亦有助事故處理：若日後發現私人端點被標成公開，負責人可找出受影響路由群組並清除，而不用猜測哪些無關資產也在其中。每種回應都有明確理由，政策便較安全，也較容易維護。

明白快取政策的保障範圍

回應標頭只是其中一項控制措施，不能取代每次請求的權限檢查，不能阻止使用者截圖，也不能清除程式主動複製到其他地方的資料。它更不能倒過來證明過去從未有中介節點把回應交給錯誤帳戶。應維持各層清單、由頭到尾測試路由，並監察可能繞過政策的設定變更。顧客提出疑慮時，只保存調查所需的最低限度操作證據，避免把敏感回應再複製到更多系統。實際目標是建立可核對、可修復的界線，而不是聲稱單靠一個標頭便能防止所有披露。