中小企如何逐步啟用內容安全政策，而不阻斷顧客操作？

先釐清內容安全政策的用途

內容安全政策（CSP）限制瀏覽器可從哪些來源載入程式及其他資源。即使網站另有漏洞，合適的政策仍可減少注入程式被執行的機會，但它不能代替輸出編碼、安全範本、套件審查和權限管理。中小企應先列出不能中斷的顧客操作，例如付款、地址搜尋、表格提交及確認訊息，再編寫政策。若嚴格的標頭令這些步驟失效，技術評分再好也不算成功。指定一人管理政策，另一人按真實顧客路徑驗證，才能把安全設定與實際服務連起來。

CSP 是每個網頁回應適用的規則，不能把一行設定不加判斷地貼進伺服器。介紹頁、會員頁、嵌入式結帳及後台需要的資源可能不同。記錄每項程式、樣式、圖片、字型、框架及網絡請求出現在哪個頁面、由誰負責、移除後會影響甚麼功能。以桌面和手機走一次正常流程，也要查看付款失敗、返回上一頁及重新提交等路徑。報告出現供應商網域，只表示需要查證；不等於應把整個網域及其子網域加入白名單。

先盤點依賴關係，再定規則

先建立簡單清單：頁面類別、資源種類、具體來源、業務用途、負責人和測試個案。分開網站自家程式，以及分析、聊天、地圖、付款等外部程式。確認每個外部標籤是否真的要在所有頁面載入；刪去不必要的標籤，可同時減少私隱和 CSP 管理負擔。標籤管理器及程式再載入的資源未必出現在原始 HTML，亦要檢查。記下行內事件處理和動態執行程式碼的地方，因嚴格政策通常會揭示這些依賴。遇到未識別項目應追查用途，不應立即加入永久寬鬆例外。

就程式載入而言，MDN 與 OWASP 指出以 nonce 或雜湊為核心的嚴格政策較有力。nonce 必須按每次回應產生，並由可信的頁面產生程式加到預期載入的程式標籤；若機械式加到所有標籤，攻擊者注入的標籤也可能獲放行。雜湊適合內容穩定的靜態行內程式，內容一改便須更新雜湊。strict-dynamic 可讓獲信任程式載入的其他程式繼承信任，故須先理解載入器。這些都是工程決策，不是可直接複製的萬用設定；暫時做不到時，應寫明較窄的過渡政策和改進計劃。

用只報告模式進行實測

先用 Content-Security-Policy-Report-Only HTTP 回應標頭發出候選政策。瀏覽器會指出可能違規的資源，但不會因候選政策而阻擋，團隊可以在顧客受影響前找出合法依賴。要收到報告，須設定接收端及相應指令；MDN 說明 Reporting-Endpoints 與 report-to 的配合，也指出 report-uri 仍有跨瀏覽器用途。單有只報告標頭，不代表報告已送達。應在瀏覽器核對回應標頭，刻意觸發一宗測試報告，確認接收端收到，並檢查內容有否包含不應收集的個人資料。

報告要按頁面與操作分類：真正必需的資源、已廢棄程式、瀏覽器擴充功能造成的雜訊，以及未知或可疑來源。修改政策前，先在乾淨的瀏覽器重現問題。報告數量不等於攻擊次數；擴充功能和測試失敗都會製造紀錄。沒有報告也不等於全站正常，少見的付款錯誤路徑可能根本未被使用。建立測試矩陣，記錄路徑、裝置、瀏覽器、預期及實際結果。盡量用測試帳戶和測試交易，並由職員檢查顧客看到的結果，不只看網絡請求的狀態碼。

以結帳流程制定啟用條件

假設網店結帳使用自家程式、託管付款框架，以及地圖地址輔助功能。只報告測試在付款返回頁和舊推廣彈窗出現違規。先核對付款框架與返回請求是否屬合約內的付款流程，分別測試成功和被拒付款；沒有用途的舊彈窗則刪除程式，而非放寬來源。為每項餘下問題記錄具體頁面及指令，因修改 script-src 未必能處理 frame-src。這是說明決策方法的假設例子，並非真實客戶成果，也不是適用所有網站的固定指令清單。

正式阻擋前，要先訂明驗收條件：關鍵顧客路徑測試通過、每個例外有負責人，以及正式環境出現阻擋時可迅速撤回標頭。測試應使用與正式部署一致的版本及路徑；預備站網域可能掩蓋付款來源、CDN 檔案或標籤設定的差異。架構容許時，先在有限頁面類別或使用群組啟用，再根據客服回報及瀏覽器證據擴大範圍。調整已執行政策期間，保留候選只報告政策，有助及早發現新增違規。

網站改動後持續維護政策

政策不會在啟用當日完成。新付款供應商、聊天工具、字型來源或網站元件上線時，應同時交代用途、更新資源清單並重測顧客路徑。定期查看報告趨勢，只對已理解的雜訊作處理，也要檢查舊例外能否移除。不要只為消除部署警告便加入 unsafe-inline，因這會削弱嚴格程式政策的重要保護。保安負責人應記下例外的理由及複查日期；產品同事則確認移除它不會妨礙真實操作。

交接時要把證據與假設分清。保存候選政策、收到的報告、乾淨瀏覽器重現紀錄、逐條路徑的測試結果、核准的供應商資源及撤回方法。日後若發生注入內容事故，這些紀錄可協助確認瀏覽器當時收到甚麼限制，以及受影響頁面是否在範圍內；它們不能證明所有注入都不可能發生。中小企可請開發或保安伙伴協助實作及測試，但仍要自行界定哪些顧客操作必須正常，以及每項外部依賴是否值得保留。

傳送方式也要刻意選擇。HTTP 回應標頭支援完整政策功能，亦可在顧客真正收到的頁面核對。meta 元素在報告及框架控制等方面有限制，不能當作與標頭完全互換。經 CDN 和反向代理後，須查看瀏覽器實際收到的回應，包括錯誤頁及快取版本；伺服器設定檔有一行字並不能證明已送達。變更紀錄要保存候選及正式政策的確切內容，日後排錯才可比對顧客當時收到的規則。

畫面看似完整，仍可能有表格提交處理、付款返回回呼或無障礙控制失效。測試應產生可核對的預期狀態，例如測試查詢確實進入指定工作隊列，事後按正常程序清理測試紀錄。相反，違規報告可能只是已阻擋的廣告標籤，並不影響顧客任務。在放行來源或宣稱沒有影響前，先記下這個分別。每項獲接受的例外都應連到能證明業務用途的測試個案。

啟用前應訂明停止條件。若正式環境的結帳、登入或查詢提交失效，值班人員須知道如何恢復上一版標頭、如何在網站邊緣核實回應已更新，以及應通知哪些內部同事。只修改來源伺服器設定、卻留下快取舊回應，不能算完成撤回。恢復服務後，保留故障證據，再在只報告模式修改候選政策，不宜反覆切換未驗證版本。小團隊才能有秩序地完成可能影響服務的保安變更。