加密之外的傳輸安全設定
加密只是第一層
安裝憑證解決了「傳輸內容被看見」的問題，但傳輸安全還有其他面向可以加強。
以下設定屬於伺服器層級，通常由廠商或維護方處理，但業主知道有這些選項，才能在需要時提出。
一、強制加密的宣告
即使設定了 http 轉向 https，訪客第一次連線時仍可能先走未加密的連線再被轉向——這個空隙理論上有被攻擊的可能。
強制加密的宣告（HSTS）可以讓瀏覽器記住「這個網站只能用加密連線」，之後即使輸入 http 也會直接改用 https，不經過未加密的那一步。
導入時要謹慎
- 一旦生效，在有效期內無法回退到 http
- 如果憑證出問題，訪客將完全無法存取網站
- 建議先設較短的有效期測試，確認一切正常再延長
- 所有子網域也要確認都有有效憑證
這是威力大但不可逆的設定，導入前務必確認網站的加密設定完全穩定。
二、安全性標頭
伺服器可以在回應中加上一些標頭，指示瀏覽器採取額外的保護。常見的幾種：
| 標頭 | 作用 |
|---|---|
| 內容安全政策 | 限制頁面可以載入哪些來源的資源，可降低跨站腳本攻擊與外掛置換的風險 |
| 內容類型嗅探防護 | 防止瀏覽器誤判檔案類型而執行不該執行的內容 |
| 框架嵌入限制 | 防止網站被嵌入他人頁面中，避免點擊挾持 |
| 參照來源政策 | 控制連出時傳遞多少來源資訊 |
內容安全政策要小心設定
它的效果最強，但也最容易設錯——設得太嚴格會讓網站的正常功能失效，例如地圖、影片、分析工具、社群外掛都可能被阻擋。
建議做法：
- 先用僅觀察的模式部署，收集會被阻擋的項目
- 確認所有正常來源都已納入
- 再切換為實際執行
我們既有的NGINX 檔頭相關設定一文中，有語法上的注意事項可以參考。
三、加密協定的版本
加密協定有版本之分，舊版本已知有安全弱點。
- 應停用已被淘汰的舊版本
- 啟用目前建議的版本
- 定期檢視，因為建議會隨時間調整
相容性的取捨
停用舊版本會讓部分老舊裝置無法連線。實務上這個影響已經很小，但如果客群包含使用舊系統的族群，可以先確認再調整。
四、用檢測工具確認等級
有線上工具可以檢測伺服器的加密設定，並給出評等。它會檢查：
- 憑證的有效性與鏈完整性
- 支援的協定版本
- 加密套件的強度
- 已知弱點
建議安裝憑證後跑一次，並每年複測。 因為評判標準會隨著新弱點被發現而調整——今年評等良好的設定，兩年後可能就不合格了。
五、Cookie 的安全設定
如果網站有登入功能，Cookie 的設定也影響安全：
- 標示為僅限加密連線傳輸
- 限制無法被前端程式讀取——降低被竊取的風險
- 限制跨站傳送——降低跨站請求偽造的風險
這些屬於程式與伺服器設定，會員系統的網站尤其應該確認。
該做到什麼程度
依網站性質判斷：
| 網站類型 | 建議 |
|---|---|
| 純展示型企業網站 | 憑證加自動續期、全站轉向即可 |
| 有表單或後台 | 加上基本的安全性標頭 |
| 有會員或交易 | 再加上 Cookie 設定與強制加密宣告 |
| 高敏感或合規需求 | 完整導入並定期檢測 |
不必一次做到最完整。 先把憑證與轉向做對，再依網站的實際風險逐步加強。
發包時可以提出的需求
- 憑證安裝與自動續期設定
- 全站轉向與混合內容清除
- 基本安全性標頭設定
- 加密設定的檢測報告
- 後續由誰負責維護與監控
最後一項要寫清楚——憑證到期、協定版本更新屬於持續性的維護工作，應在合約或維護方案中界定責任。
保固與維護的界線見保固與維護有什麼不同。
憑證的類型、有效期限、瀏覽器的呈現方式與相關規範會不定期調整，本文說明的是原則與判斷方式。實際規格請以憑證核發單位與瀏覽器官方之現行公告為準。