TLS 配置
問題
如果透過 Web 傳送未加密的資料，它可能會被第三方攔截，從而使他們能夠訪問和修改資料 — 這通常被稱為 中間人攻擊 (MiTM)。MiTM 攻擊會對您的系統安全造成嚴重後果。
因此，所有請求和響應都應透過 HTTPS 傳送，HTTPS 使用 TLS 來加密資料。現代 Web 幾乎強制執行此要求 — 所有瀏覽器都正朝著預設要求 HTTPS 的方向發展，並且許多 Web 功能只能在 安全上下文 中使用。
解決方案
您應該設定伺服器軟體以使用安全的配置，強制使用帶有安全 TLS 設定的 HTTPS。有幾種 TLS 配置生成器可供使用，例如 Mozilla 的 SSL 配置生成器。此工具提供了基於 Mozilla TLS 指南 的幾個選項。
資源載入
問題
所有資源，無論其來源如何，都應透過安全通道載入。
安全 (HTTPS) 網站嘗試透過不安全連線 (HTTP) 載入活動資源 (如 JavaScript) 將被瀏覽器阻止。因此，使用者將遇到 UI 降級和 混合內容 警告。例如，在下面的程式碼中，不正確地使用 HTTP 來載入 JavaScript 庫
<script src="http://code.jquery.com/jquery-1.12.0.min.js"></script>
同樣，嘗試不安全地載入影像等被動內容，雖然風險較低，但仍會導致 UI 降級和混合內容警告，並可能允許活動攻擊者篡改網站或進行使用者網路釣魚。例如
<img src="http://very.badssl.com/image.jpg" />
儘管現代瀏覽器會清楚地標明網站何時不安全地載入資源，但這些錯誤仍然在 Web 上頻繁發生。
解決方案
在部署之前，請驗證所有資源是否都透過 HTTPS 載入。
示例
在此示例中，正在正確使用 HTTPS 來載入 JavaScript 庫
<script src="https://code.jquery.com/jquery-1.12.0.min.js"></script>
HTTP 重定向
問題
網站可能繼續監聽埠 80 (HTTP) 以防止使用者在位址列中鍵入 URL 時出現連線錯誤，因為初始瀏覽器連線通常是透過 HTTP 進行的。在首次連線到站點時，這會帶來初始安全風險，因為該連線不受 TLS 保護。
此外，站點應避免從一個主機的 HTTP 重定向到另一個主機的 HTTPS，因為這會阻止為第一個主機設定 Strict-Transport-Security（請參閱 HTTP 嚴格傳輸安全）。
解決方案
監聽埠 80 的站點應僅重定向到 HTTPS 上的相同資源。一旦發生重定向，Strict-Transport-Security 應確保將來所有透過 HTTP 訪問站點的嘗試都自動重定向到安全站點。
不打算公開訪問的 API 或網站應完全停用 HTTP 的使用。
修復“不同主機”問題
- 首先，將 http://example.com/ 重定向到 https://example.com/。
- 接下來，將 https://example.com/ 重定向到 https://example.org/。
示例
使用 NGINX 將所有入站 HTTP 請求重定向到同一站點和 URI 的 HTTPS 版本
server {
listen 80;
return 301 https://$host$request_uri;
}
使用 Apache 將 site.example.org 從 HTTP 重定向到 HTTPS
<VirtualHost *:80>
ServerName site.example.org
Redirect permanent / https://site.example.org/
</VirtualHost>
HTTP 嚴格傳輸安全實現
問題
為了防止 中間人攻擊 (MiTM)，瀏覽器應僅透過 HTTPS 連線到站點。
解決方案
HTTP Strict-Transport-Security (HSTS) 是一個 HTTP 標頭，它通知瀏覽器僅透過 HTTPS 連線到給定站點，即使最初指定的方案是 HTTP。為給定站點設定了 HSTS 的瀏覽器將自動將該站點上的所有請求升級為 HTTPS。HSTS 還透過停用繞過證書錯誤頁面的功能，指示瀏覽器更嚴格地處理 TLS 和證書相關的錯誤。
Strict-Transport-Security 支援以下指令
max-age-
設定瀏覽器將重定向到 HTTPS 的持續時間（以秒為單位）。
includeSubDomains可選-
指定瀏覽器是否應將所有子域上的請求升級到 HTTPS。例如，在
domain.example.com上設定includeSubDomains將確保對host1.domain.example.com和host2.domain.example.com的請求除了domain.example.com本身之外也會被升級。 preload可選-
指定是否應預載入該站點。包含此指令意味著您的站點可以包含在 HSTS 預載入列表 中。
請遵循以下步驟正確地在您的網站上實現 HSTS
- 將
max-age值設定為至少六個月 (15768000)。建議設定更長的時間，例如兩年 (63072000)。設定此值後，站點必須在到期時間到達之前繼續支援 HTTPS。 - 如果可能，設定
includeSubDomains以提高所有子域的安全性。設定此指令時需要仔細測試，因為它可能會停用尚未啟用 HTTPS 的子域上的站點。 - 如果可能，設定
preload以便將您的網站包含在 HSTS 預載入列表中。要將其新增到列表中，請訪問 https://hstspreload.org/，然後在頁面頂部的表單中輸入您的站點 URL，並修復它提到的任何問題。Web 瀏覽器將在收到初始Strict-Transport-Security標頭之前，對預載入的站點執行 HTTPS 升級。這可以防止首次使用時發生 降級攻擊，並且推薦用於所有高風險網站。請注意，包含在 HSTS 預載入列表中還需要設定includeSubDomains，並將max-age設定為至少 1 年 (31536000)。
除了 Strict-Transport-Security 之外，您還應在您的 Content-Security-Policy 中設定 upgrade-insecure-requests 指令。這指示瀏覽器將站點上的所有不安全 URL (透過 HTTP 提供的 URL) 視為透過 HTTPS 提供。upgrade-insecure-requests 旨在用於擁有大量需要重寫的舊不安全 URL 的網站。
示例
建議透過 HTTPS 連線站點兩年
Strict-Transport-Security: max-age=63072000
如果可能，另外升級子域請求到 HTTPS，並將站點包含在預載入列表中
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
同時設定 upgrade-insecure-requests CSP
Content-Security-Policy: upgrade-insecure-requests;