中小企如何啟用 HSTS，同時避免子網域無法連線？

先弄清瀏覽器會作甚麼決定

HSTS 是由 HTTPS 回應傳給瀏覽器的指令。瀏覽器收到有效的 Strict-Transport-Security 標頭後，會在 max-age 指定的期間記住該主機，日後把 HTTP 嘗試改為 HTTPS；遇到憑證錯誤時，訪客亦不能簡單按鍵略過。它有助減少舊 HTTP 連結帶來的風險，卻不能修好過期憑證或設定錯誤的伺服器。因此，真正要決定的是所有受影響主機能否在整段有效期維持可靠的 HTTPS。

一般 HTTP 轉往 HTTPS 的重新導向，與 HSTS 處理的是不同時點。首次到訪而瀏覽器沒有預載規則時，瀏覽器可能先發出 HTTP 請求，然後才看到轉址和 HTTPS 標頭。HSTS 是瀏覽器學會規則後保護往後的請求。預載可涵蓋首次連線，但加入瀏覽器預載清單影響更廣，撤回亦較困難。不能單憑轉址、標頭或提交預載申請就宣稱整段路徑安全；應分別測試新瀏覽器和已記住規則的瀏覽器。

改設定前先寫清規則範圍。由 shop.example.com 發出的規則作用於該主機；加入 includeSubDomains，才會延伸至該主機以下的名稱。因此，example.com 的規則如包含此指令，可能連網店、預約頁和舊活動子網域都受影響。未預載時，瀏覽器須先到訪上層主機才學到其規則；子網域也可能各自保留獨立規則。把範圍畫在主機清單上，讓市場、客服和技術同事談的是同一批網址。

瀏覽器每次再收到標頭，都會重新計算 max-age 到期時間。因此，網站若持續發出原標頭，對經常到訪的訪客而言，看似短暫的試行規則也可能延續。不要假設初期數值短，首日測試後便自然消失。應在設定變更紀錄標明覆核日期，屆時明確決定保留、延長還是移除。若營運交由另一供應商，交接資料也須列出 HSTS 狀態；新供應商即使並非原設定者，仍要維持有效 HTTPS。網域擁有人與網站供應商不同時，這項交接尤其重要。如有多個代理或 CDN 設定，交接亦要註明標頭在哪一層加入，避免新團隊只檢查應用程式原始回應，卻漏掉公開連線真正收到的規則。覆核時從外部網絡重新取得回應，並把結果與記錄中的預期範圍對照。

盤點主機與失效路徑

從 DNS 紀錄、邊緣服務與主機設定、憑證清單、舊轉址規則和發給顧客的連結開始。不要漏掉少用的退貨入口、供應商登入、短期推廣頁、付款回調或仍能解析的舊子網域。即使有萬用字元憑證，也要查每個主機名稱實際連往哪個服務、是否真的提供合適憑證，以及應用程式能否在 HTTPS 下運作。逐項記錄負責人、使用者、HTTP 現況、憑證覆蓋和續期責任。

不要只看到首頁顯示安全鎖就當作完成。以 HTTPS 打開具代表性的內頁，核對憑證涵蓋該主機名稱，跟隨轉址；適當時提交不影響真實業務的測試查詢，再查資源及回調是否正常。檢查公開邊緣服務的回應，而不只是原始伺服器：CDN、負載平衡器或另一個主機可能新增、刪除或重複標頭。若有裸網域和 www，兩者都要測試。打算停用的舊主機應先真正處理，不能等待廣泛規則令其 HTTP 專用頁失效後才發現。

要分清真正的 HTTPS 故障與瀏覽器記住舊規則造成的現象。用乾淨的瀏覽器設定檔觀察首次連線，再讓它收到標頭後重試；每次記錄回應標頭及最終網址。HTTP 回應即使帶有該標頭，也不會令瀏覽器建立 HSTS，因為規則由 HTTPS 學到。若某設定檔之前見過較長 max-age，伺服器改設定後也可能繼續受影響。因此，使用測試主機和已知狀態的瀏覽器，比管理員不斷刷新同一個分頁更有參考價值。

分階段啟用並訂出停止條件

先在已證實 HTTPS 正常的主機使用短有效期規則。Chrome 指引以 max-age=3600 作初期例子，並在一段平穩觀察期後以 604800 作下一階段例子。這是分階段做法的示例，不代表每間公司觀察一星期就足夠。觀察期須涵蓋服務真正使用周期，例如每月才使用的帳單入口或季節性活動頁。只有各服務負責人確認相關流程和憑證續期控制正常，才延長有效期。

把 includeSubDomains 視為另一次擴大範圍的決定，不要隨手加在設定檔。於上層網域採用前，列出現有及已計劃的所有子網域，取得各個運作中主機的 HTTPS 證據，並由負責人核對。使用公司子網域的外判市場或客服工具也要納入。若供應商尚未能正確支援 HTTPS，先採用較窄的單一主機規則，處理相依問題後再擴大。顧客在供應商主機遇上不能略過的憑證錯誤，不會因為它由另一團隊管理而較少受影響。

回復方案必須如實考慮瀏覽器記憶。在正常運作的 HTTPS 回應送出 max-age=0，可要求瀏覽器移除該主機已學到的規則；但瀏覽器必須先成功收到那個有效 HTTPS 回應。它不能移除另一主機獨立學到的規則，也不能把已進入瀏覽器預載清單的項目即時撤回。若憑證故障，首要工作是恢復有效 HTTPS，不能指望受影響瀏覽器接收不到的標頭。把緊急憑證及路由聯絡人放進啟用紀錄。

以混合主機例子作決定

假設一間網店的主站、帳戶頁與預約子網域都使用 HTTPS，但舊活動子網域仍只提供 HTTP 登陸頁。店主想在上層網域一次設定強力 HSTS。主機盤點會顯示，若在上層採用 includeSubDomains，瀏覽器會把前往舊活動主機的連線升級；在它支援 HTTPS 或停用前，頁面便可能失效。合理的第一步是修好或關閉舊主機，核實其他流程，再試行短有效期的上層規則。這只是供規劃的例子，不是真實客戶成效。

再加入一個只在月底使用的供應商入口。一天試行期沒有投訴，對這入口並無多少證明。安排測試帳戶和負責人，在延長規則前實際登入、下載及登出。若入口由第三方服務提供，應索取公司自訂主機名稱和續期流程的證據，不要以供應商品牌推定一切正常。這個使用時間細節會改變決定：應在實際流程獲覆蓋後才升級規則，而不只是等時間過了一星期。

預載應放在這段工作的最後。MDN 指出，preload 指令須配合 includeSubDomains，並至少設定一年 max-age；把網域提交至預載服務是額外步驟，並非標頭寫了 preload 就自動完成。承諾前須核對預載服務現行要求及撤回後果。若中小企尚未能清楚掌握未來子網域，經妥善測試但未預載的規則，可能是目前更負責任的狀態。把它記錄為有意識的範圍選擇，不要把稽核分數當成業務目的。

留下可驗收的證據

有用的驗收紀錄應包含主機清單版本、公開 HTTPS 回應實際送出的標頭、首次與再次到訪測試的日期和瀏覽器狀態、憑證與主機名稱的核對結果、已測流程、例外，以及每項未解問題的負責人。記下所選 max-age 及其如何涵蓋已測的營運周期。每階段監察 HTTPS 故障、憑證到期訊號及顧客反映。日後維護者才能分辨有意設定的規則與代理伺服器的意外設定，延長規則亦成為可審核的決定。

最後要向決策者解釋剩餘界限。瀏覽器學到 HSTS 後，它是一項強制傳輸規則，但並非完整網站安全審查、憑證監察服務，也不證明所有後端連線已加密。若眼前問題是憑證失效或沒有 HTTPS 端點，須先修好。若問題是舊 HTTP 連結，部署 HSTS 後仍要維持正常的 HTTPS 轉址。清楚劃界有助店主為真正的修復撥資源，避免把一個安全標頭當作整個網站的營運方案。