安全 HTTP 響應頭

本文件的這部分討論了安全 HTTP 響應頭的一般主題。有關基於 servlet 和 WebFlux 應用程式中安全 HTTP 響應頭的具體資訊，請參閱相關章節。

您可以透過多種方式使用 HTTP 響應頭來提高 Web 應用程式的安全性。本節專門討論 Spring Security 明確支援的各種 HTTP 響應頭。如有必要，您還可以配置 Spring Security 以提供自定義頭。

預設安全頭

有關如何為基於 servlet 和 webflux 的應用程式自定義預設值，請參閱相關章節。

Spring Security 提供了一組預設的安全相關 HTTP 響應頭，以提供安全的預設設定。

Spring Security 的預設設定是包含以下頭

預設安全 HTTP 響應頭

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 0

Strict-Transport-Security 僅新增到 HTTPS 請求中

如果預設設定不滿足您的需求，您可以輕鬆地從這些預設設定中刪除、修改或新增頭。有關每個頭的更多詳細資訊，請參閱相應的章節

快取控制
內容型別選項
HTTP 嚴格傳輸安全
X-Frame-Options
X-XSS-Protection

快取控制

有關如何為基於 servlet 和 webflux 的應用程式自定義預設值，請參閱相關章節。

Spring Security 的預設設定是停用快取以保護使用者的內容。

如果使用者進行身份驗證以檢視敏感資訊，然後登出，我們不希望惡意使用者能夠點選後退按鈕來檢視敏感資訊。預設傳送的快取控制頭是

預設快取控制 HTTP 響應頭

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0

為了預設安全，Spring Security 預設新增這些頭。但是，如果您的應用程式提供了自己的快取控制頭，Spring Security 會退出。這允許應用程式確保靜態資源（如 CSS 和 JavaScript）可以被快取。

內容型別選項

請參閱相關章節，瞭解如何為基於 servlet 和 webflux 的應用程式自定義預設值。

在過去，包括 Internet Explorer 在內的瀏覽器會嘗試透過內容嗅探來猜測請求的內容型別。這使得瀏覽器可以透過猜測未指定內容型別的資源的內容型別來改善使用者體驗。例如，如果瀏覽器遇到一個未指定內容型別的 JavaScript 檔案，它將能夠猜測內容型別並執行它。

在允許上傳內容時，還有許多其他事情應該做（例如，僅在不同的域中顯示文件，確保設定 Content-Type 頭，清理文件等）。但是，這些措施超出了 Spring Security 提供的範圍。還需要指出的是，當停用內容嗅探時，您必須指定內容型別才能使功能正常工作。

內容嗅探的問題在於，這允許惡意使用者使用多語言檔案（即，一個檔案可以有多種內容型別）來執行 XSS 攻擊。例如，某些網站可能允許使用者向網站提交有效的 postscript 文件並檢視它。惡意使用者可能會建立一個既是 postscript 文件又是有效 JavaScript 檔案的檔案，並用它執行 XSS 攻擊。

預設情況下，Spring Security 透過向 HTTP 響應新增以下頭來停用內容嗅探

nosniff HTTP 響應頭

X-Content-Type-Options: nosniff

HTTP 嚴格傳輸安全 (HSTS)

請參閱相關章節，瞭解如何為基於 servlet 和 webflux 的應用程式自定義預設值。

當您輸入銀行網站時，您是輸入 mybank.example.com 還是輸入 https://mybank.example.com？如果您省略 https 協議，您可能會受到中間人攻擊的攻擊。即使網站執行重定向到 https://mybank.example.com，惡意使用者也可能攔截初始 HTTP 請求並操縱響應（例如，重定向到 https://mibank.example.com 並竊取其憑據）。

許多使用者會省略 https 協議，這就是 HTTP 嚴格傳輸安全 (HSTS) 被建立的原因。一旦 mybank.example.com 被新增為 HSTS 主機，瀏覽器可以提前知道對 mybank.example.com 的任何請求都應被解釋為 https://mybank.example.com。這大大降低了中間人攻擊發生的可能性。

根據 RFC6797，HSTS 頭僅注入到 HTTPS 響應中。為了讓瀏覽器識別該頭，瀏覽器必須首先信任用於建立連線的 SSL 證書的 CA（而不僅僅是 SSL 證書）。

將站點標記為 HSTS 主機的一種方法是將其預載入到瀏覽器中。另一種方法是將 Strict-Transport-Security 頭新增到響應中。例如，Spring Security 的預設行為是新增以下頭，該頭指示瀏覽器將該域視為一年的 HSTS 主機（非閏年有 31536000 秒）

嚴格傳輸安全 HTTP 響應頭

Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload

可選的 includeSubDomains 指令指示瀏覽器子域（例如 secure.mybank.example.com）也應被視為 HSTS 域。

可選的 preload 指令指示瀏覽器應將該域預載入到瀏覽器中作為 HSTS 域。有關 HSTS 預載入的更多詳細資訊，請參閱 hstspreload.org。

HTTP 公鑰固定 (HPKP)

為了保持被動，Spring Security 仍然在 servlet 環境中提供對 HPKP 的支援。然而，由於前面列出的原因，Spring Security 團隊不再推薦使用 HPKP。

HTTP 公鑰固定 (HPKP) 向 Web 客戶端指定要與特定 Web 伺服器一起使用的公鑰，以防止使用偽造證書的中間人 (MITM) 攻擊。如果使用正確，HPKP 可以為受損證書增加額外的保護層。但是，由於 HPKP 的複雜性，許多專家不再推薦使用它，並且 Chrome 甚至取消了對它的支援。

有關不再推薦 HPKP 的更多詳細資訊，請閱讀 HTTP 公鑰固定已死？和我放棄 HPKP 了。

X-Frame-Options

請參閱相關章節，瞭解如何為基於 servlet 和 webflux 的應用程式自定義預設值。

允許您的網站被新增到框架中可能會帶來安全問題。例如，透過使用巧妙的 CSS 樣式，使用者可能會被欺騙點選他們無意點選的東西。例如，登入銀行的使用者可能會點選一個授予其他使用者訪問許可權的按鈕。這種攻擊被稱為點選劫持。

處理點選劫持的另一種現代方法是使用內容安全策略 (CSP)。

有多種方法可以緩解點選劫持攻擊。例如，為了保護舊版瀏覽器免受點選劫持攻擊，您可以使用框架破壞程式碼。雖然不完美，但框架破壞程式碼是舊版瀏覽器最好的選擇。

解決點選劫持的一種更現代的方法是使用 X-Frame-Options 頭。預設情況下，Spring Security 使用以下頭停用在 iframe 中渲染頁面

X-Frame-Options: DENY

X-XSS-Protection

請參閱相關章節，瞭解如何為基於 servlet 和 webflux 的應用程式自定義預設值。

某些瀏覽器內建了過濾反射型 XSS 攻擊的支援。該過濾器已在主要瀏覽器中棄用，當前的 OWASP 建議是明確將該頭設定為 0。

預設情況下，Spring Security 透過使用以下頭來阻止內容

X-XSS-Protection: 0

內容安全策略 (CSP)

請參閱相關章節，瞭解如何配置基於 servlet 和 webflux 的應用程式。

內容安全策略 (CSP) 是一種 Web 應用程式可用於緩解內容注入漏洞（如跨站指令碼 (XSS)）的機制。CSP 是一種宣告性策略，它為 Web 應用程式作者提供了一種工具，用於宣告並最終告知客戶端（使用者代理）Web 應用程式期望從哪些來源載入資源。

內容安全策略並非旨在解決所有內容注入漏洞。相反，您可以使用 CSP 來幫助減少內容注入攻擊造成的危害。作為第一道防線，Web 應用程式作者應驗證其輸入並編碼其輸出。

Web 應用程式可以透過在響應中包含以下 HTTP 頭之一來使用 CSP

Content-Security-Policy
Content-Security-Policy-Report-Only

這些頭都用作向客戶端傳遞安全策略的機制。安全策略包含一組安全策略指令，每個指令負責宣告特定資源表示的限制。

例如，Web 應用程式可以透過在響應中包含以下頭來宣告它期望從特定受信任來源載入指令碼

內容安全策略示例

Content-Security-Policy: script-src https://trustedscripts.example.com

嘗試從 script-src 指令中宣告的來源以外的來源載入指令碼將被使用者代理阻止。此外，如果在安全策略中聲明瞭 report-uri 指令，則使用者代理會將違規情況報告給宣告的 URL。

例如，如果 Web 應用程式違反了宣告的安全策略，則以下響應頭會指示使用者代理將違規報告發送到策略的 report-uri 指令中指定的 URL。

帶 report-uri 的內容安全策略

Content-Security-Policy: script-src https://trustedscripts.example.com; report-uri /csp-report-endpoint/

違規報告是標準的 JSON 結構，可以透過 Web 應用程式自己的 API 或公開託管的 CSP 違規報告服務（例如 report-uri.io/）捕獲。

Content-Security-Policy-Report-Only 頭為 Web 應用程式作者和管理員提供了監控安全策略而不是強制執行它們的能力。此頭通常用於試驗或開發網站的安全策略。當策略被認為有效時，可以使用 Content-Security-Policy 頭欄位來強制執行它。

鑑於以下響應頭，策略宣告指令碼可以從兩種可能的來源之一載入。

僅內容安全策略報告

Content-Security-Policy-Report-Only: script-src 'self' https://trustedscripts.example.com; report-uri /csp-report-endpoint/

如果站點違反此策略，嘗試從 evil.example.com 載入指令碼，則使用者代理會將違規報告發送到 report-uri 指令指定的宣告 URL，但仍允許載入違規資源。

將內容安全策略應用於 Web 應用程式通常不是一項簡單的任務。以下資源可能有助於為您的網站開發有效的安全策略

內容安全策略簡介

CSP 指南 - Mozilla 開發者網路

W3C 候選推薦標準

Referrer Policy（引用策略）

請參閱相關章節，瞭解如何配置基於 servlet 和 webflux 的應用程式。

Referrer Policy（引用策略）是一種 Web 應用程式可用於管理包含使用者上次訪問頁面的引用欄位的機制。

Spring Security 的方法是使用 Referrer Policy 頭，它提供了不同的策略

Referrer Policy 示例

Referrer-Policy: same-origin

Referrer-Policy 響應頭指示瀏覽器讓目標知道使用者之前所在的來源。

功能策略

請參閱相關章節，瞭解如何配置基於 servlet 和 webflux 的應用程式。

功能策略是一種機制，它允許 Web 開發人員選擇性地啟用、停用和修改瀏覽器中某些 API 和 Web 功能的行為。

功能策略示例

Feature-Policy: geolocation 'self'

透過功能策略，開發人員可以為瀏覽器選擇一組“策略”，以強制執行您網站中使用的特定功能。這些策略限制了網站可以訪問的 API 或修改了瀏覽器某些功能的預設行為。

許可權策略

請參閱相關章節，瞭解如何配置基於 servlet 和 webflux 的應用程式。

許可權策略是一種機制，它允許 Web 開發人員選擇性地啟用、停用和修改瀏覽器中某些 API 和 Web 功能的行為。

許可權策略示例

Permissions-Policy: geolocation=(self)

透過許可權策略，開發人員可以為瀏覽器選擇一組“策略”，以強制執行您網站中使用的特定功能。這些策略限制了網站可以訪問的 API 或修改了瀏覽器某些功能的預設行為。

清除站點資料

請參閱相關章節，瞭解如何配置基於 servlet 和 webflux 的應用程式。

清除站點資料是一種機制，當 HTTP 響應包含此頭時，可以刪除任何瀏覽器端資料（cookie、本地儲存等）

Clear-Site-Data: "cache", "cookies", "storage", "executionContexts"

這是一個在登出時執行的很好的清理操作。

自定義頭

請參閱相關章節，瞭解如何配置基於 servlet 的應用程式。

Spring Security 具有方便的機制，可以輕鬆地將更常見的安全頭新增到您的應用程式中。但是，它還提供了鉤子以啟用新增自定義頭。