安全 HTTP 回應標頭

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

您可以使用 HTTP 回應標頭以多種方式增強網路應用程式的安全性。本節專門介紹 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 請求上添加

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

快取控制

有關如何自訂基於 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 Strict Transport Security (HSTS)

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

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

許多使用者省略了 https 協定，這就是為什麼建立HTTP Strict Transport Security (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 秒)

Strict Transport Security HTTP 回應標頭
Strict-Transport-Security: max-age=31536000 ; includeSubDomains ; preload

可選的 includeSubDomains 指令指示瀏覽器也應將子網域 (例如 secure.mybank.example.com) 視為 HSTS 網域。

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

HTTP Public Key Pinning (HPKP)

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

HTTP Public Key Pinning (HPKP) 向網路用戶端指定要與特定網路伺服器一起使用的公鑰，以防止使用偽造憑證的中間人 (MITM) 攻擊。如果使用正確，HPKP 可以增加額外的保護層，以防止憑證洩露。但是，由於 HPKP 的複雜性，許多專家不再建議使用它，並且 Chrome 甚至移除了對它的支援。

有關為什麼不再建議使用 HPKP 的更多詳細資訊，請閱讀 HTTP Public Key Pinning 已死嗎？ 和 我放棄 HPKP 了。

X-Frame-Options

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

讓您的網站被添加到框架中可能是一個安全問題。例如，通過使用巧妙的 CSS 樣式，使用者可能會被欺騙點擊他們不打算點擊的東西。例如，已登入銀行的使用者可能會點擊一個按鈕，該按鈕授予其他使用者存取權限。這種攻擊稱為 點擊劫持。

處理點擊劫持的另一種現代方法是使用 Content Security Policy (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

Content Security Policy (CSP)

有關如何組態基於 servlet 和 webflux 的應用程式的資訊，請參閱相關章節。

Content Security Policy (CSP) 是一種機制，網路應用程式可以使用它來緩解內容注入漏洞，例如跨網站腳本 (XSS)。CSP 是一種宣告式策略，它為網路應用程式作者提供了一種宣告並最終告知用戶端 (使用者代理) 網路應用程式期望從中載入資源的來源的工具。

Content Security Policy 無意解決所有內容注入漏洞。相反，您可以使用 CSP 來幫助減少內容注入攻擊造成的危害。作為第一道防線，網路應用程式作者應驗證其輸入並編碼其輸出。

網路應用程式可以通過在回應中包含以下 HTTP 標頭之一來使用 CSP

  • Content-Security-Policy

  • Content-Security-Policy-Report-Only

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

例如，網路應用程式可以通過在回應中包含以下標頭來宣告它期望從特定的受信任來源載入腳本

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

嘗試從 script-src 指令中宣告的來源以外的其他來源載入腳本會被使用者代理阻止。此外，如果在安全策略中宣告了 report-uri 指令，則違規將由使用者代理報告給宣告的 URL。

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

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

違規報告是標準 JSON 結構，可以由網路應用程式自己的 API 或公共託管的 CSP 違規報告服務 (例如 report-uri.io/) 捕獲。

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

給定以下回應標頭，該策略宣告可以從兩個可能的來源之一載入腳本。

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

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

將 Content Security Policy 應用於網路應用程式通常是一項非平凡的任務。以下資源可能為您的網站開發有效的安全策略提供進一步的幫助

Content Security Policy 簡介

CSP 指南 - Mozilla 開發人員網路

W3C 候選推薦

Referrer Policy

有關如何組態基於 servlet 和 webflux 的應用程式的資訊，請參閱相關章節。

Referrer Policy 是一種機制，網路應用程式可以使用它來管理 referrer 欄位，該欄位包含使用者上次所在的頁面。

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

Referrer Policy 範例
Referrer-Policy: same-origin

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

Feature Policy

有關如何組態基於 servlet 和 webflux 的應用程式的資訊，請參閱相關章節。

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

Feature Policy 範例
Feature-Policy: geolocation 'self'

借助 Feature Policy，開發人員可以選擇加入一組「策略」，供瀏覽器在整個網站中使用的特定功能上強制執行。這些策略限制了網站可以存取的 API 或修改瀏覽器某些功能的預設行為。

Permissions Policy

有關如何組態基於 servlet 和 webflux 的應用程式的資訊，請參閱相關章節。

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

Permissions Policy 範例
Permissions-Policy: geolocation=(self)

借助 Permissions Policy，開發人員可以選擇加入一組「策略」，供瀏覽器在整個網站中使用的特定功能上強制執行。這些策略限制了網站可以存取的 API 或修改瀏覽器某些功能的預設行為。

清除網站資料

有關如何組態基於 servlet 和 webflux 的應用程式的資訊，請參閱相關章節。

清除網站資料 是一種機制，通過該機制，當 HTTP 回應包含此標頭時，可以移除任何瀏覽器端資料 (cookie、本地儲存等等)

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

這是登出時要執行的一個不錯的清理操作。

自訂標頭

有關如何組態基於 servlet 的應用程式的資訊，請參閱相關章節。

Spring Security 具有使其可以方便地將更常見的安全標頭添加到您的應用程式的機制。但是，它也提供了掛鉤以啟用新增自訂標頭。