HTTP 頭對于增強 Web 安全性至關重要，是任何人都可以實現的最簡單的安全措施之一。使用適當的 HTTP 響應頭可以降低潛在的安全風險，如跨站腳本（XSS）、點擊劫持、信息泄露以及其他許多漏洞。這些頭部信息作為第一道防護盾，保護 Web 應用程序免受惡意攻擊。

HTTP協議概述

HTTP 頭是超文本傳輸協議（HTTP）的一個組成部分，HTTP 是萬維網上數據通信的基礎。HTTP 頭是在 HTTP 請求（即 HTTP 請求頭）或響應（即 HTTP 響應頭）中包含的額外信息行。它們提供了有關請求或響應的關鍵信息，使客戶端和服務器能夠有效地通信。

HTTP 頭由鍵值對組成，其中鍵表示所傳達的具體信息，值提供相應的數據。發送方將這些頭部信息包含在 HTTP 消息的頭部部分。

圖片

HTTP 頭有多種類型，每種類型都有特定的用途。以下是一些常用頭及其功能：

• Content-Length：定義消息體的大小（以字節為單位）。
• User-Agent：標識發出 HTTP 請求的軟件（例如，網絡瀏覽器）。
• Accept：指定客戶端能夠理解并在響應中接受的媒體類型。
• Location：用于 HTTP 重定向，向客戶端提供新的 URL。
• Server：指示處理請求的軟件或服務器名稱。

HTTP 請求和響應頭支持內容協商、緩存、認證和會話管理等多種功能。它們在客戶端與服務器之間的通信中起著至關重要的作用，確保信息的高效交換以及請求和響應的正確處理。

以下是與 Web 域或頁面安全相關的所有 HTTP 請求和響應頭:

Access-Control-Allow-Origin安全頭 

Content-Type 

Content-Security-Policy (CSP) 安全頭 

Cross-Origin-Embedder-Policy 安全頭 

Cross-Origin-Resource-Policy 安全頭 

Cross-Origin-Opener-Policy 安全頭 

Set-Cookie 

Strict-Transport-Security (HSTS) 安全頭 

Referrer-Policy  

X-Content-Type-Options 安全頭 

X-Frame-Options 安全頭 

X-XSS-Protection 安全頭 

X-Permitted-Cross-Domain-Policies 安全頭 

Cache-Control 

X-Powered-By 

Public-Key-Pins(HPKP)

圖片

Access-Control-Allow-Origin

“Access-Control-Allow-Origin”響應頭表明服務器是否允許來自特定來源的代碼共享響應內容，通過控制跨域資源共享（CORS）來強化安全性。

跨域資源共享（CORS）機制依賴于 Access-Control-Allow-Origin 頭。此頭用于確定特定來源的代碼是否可以共享所請求的資源。

例如，當站點A請求站點B的資源時，站點B的響應中包含 Access-Control-Allow-Origin 頭，以指示站點A是否可以訪問和獲取該資源。如果該頭不允許訪問，同源策略（SOP）將阻止該請求。

圖片

默認情況下，網站受同源策略（Same Origin Policy, SOP）的保護，該策略限制了不同來源之間的資源共享。然而，通過設置 Access-Control-Allow-Origin 頭，可以在特定情況下放寬這種控制。

Access-Control-Allow-Origin:*

“Access-Control-Allow-Origin”響應頭允許來自任何來源的代碼訪問特定資源，從而提高跨域的可訪問性和靈活性。在響應中包含此頭表明對資源的無限制訪問。在上述示例中，將 Access-Control-Allow-Origin 頭的值設置為 "*" 可能看似方便，但這就像把我們網站的大門敞開讓所有人進入。正如我們不會將家門鑰匙交給陌生人一樣，我們也不應對 Web 資源給予不受限制的訪問權限。

使用 "*" 作為值，意味著我們允許任何網站向我們的服務器發送請求，這會帶來潛在的安全風險，例如跨站請求偽造（CSRF）和跨站腳本包含（XSSI）。為了保持強大的安全態勢，必須謹慎選擇并驗證頭部中的來源。這樣做可以幫助我們控制哪些網站可以安全地訪問資源。

Access-Control-Allow-Origin: https://sample.com

該響應包含 "Access-Control-Allow-Origin" 頭，使瀏覽器允許來自特定來源 "https://sample.com" 的代碼訪問請求的資源，實現安全的跨域訪問。

服務器會將“Origin”請求頭與允許的來源列表進行比較。如果找到匹配的“Origin”值，服務器會將“Access-Control-Allow-Origin”值設置為與“Origin”值相同，以限制允許的來源，從而確保安全的跨域通信。

Content-Type

“Content-Type”頭指定了正在發送或請求的資源的媒體類型。它通過確保數據的正確處理和解釋，提供了一項安全功能，有助于防止惡意內容的執行或接收方對數據的誤解。

圖片

Content-Type 頭對于 Web 安全至關重要，因為它在內容編碼之前指定了資源的原始媒體類型。它確保客戶端的正確解釋，并有助于防止諸如跨站腳本（XSS）等安全風險。

該頭設置方法如下:

Content-Type: text/html; charset=UTF-8
Content-Type: multipart/form-data; boundary=sample

Media-type“Content-Type”頭通過 MIME 類型（多用途互聯網郵件擴展）提供有關正在發送或接收的數據類型或資源的具體信息。

Charset“charset”指的是用于數據的字符編碼標準。它指定了內容中的字符應如何被解釋和顯示，建議使用小寫字符格式。

Boundary“boundary”指令對于多部分實體是必要的。它包含 1 到 70 個強健字符（不包括空白），用于標記消息部分的邊界，通常前后會加上兩個連字符。

在處理由客戶端呈現的不可信資源時，必須重視 Content-Type 頭。通過設置適當的 Content-Type，開發人員可以降低 XSS 攻擊的可能性，從而保障其 Web 應用程序的安全性和可靠性。

Content-Security-Policy (CSP)

內容安全策略（CSP）是一項安全措施，可檢測并緩解跨站腳本（XSS）和數據注入等攻擊。通過對網站加載和執行資源的方式施加嚴格規則，CSP可以防止數據泄露、網站篡改以及惡意軟件分發。

圖片

Content-Security-Policy: policy

此值表示 CSP 使用一個由策略指令組成的字符串來定義網站的安全策略規則。

Content-Security-Policy: default-src 'self'

使用此值時，網站管理員旨在將內容限制為僅從網站的源地址加載，不包括子域。

Content-Security-Policy: default-src 'self' example.com 
*.example.com

網站管理員意圖允許內容來自一個受信任的域及其所有子域，不論其是否為設置 CSP 頭的同一域。

Content-Security-Policy: default-src 'self'; img-src *; media-src example.org example.net; script-src userscripts.example.com

網站管理員希望允許應用用戶在其內容中包含來自任何來源的圖像，同時將音視頻媒體限制為特定可信提供商，并允許腳本僅來自托管受信代碼的特定服務器。

Content-Security-Policy: default-src https://sample.com

Sample網站的管理員希望對所有內容加載強制使用 TLS（傳輸層安全協議），以防止未經授權的請求訪問，從而抵御竊聽攻擊。

Content-Security-Policy: default-src 'self' *.example.com; img-src *

使用上述值時，網站管理員意圖允許郵件中的 HTML 和圖像，但限制包含 JavaScript 或其他潛在有害內容以增強安全性。該示例未顯式指定“script-src”指令，因此使用“default-src”指令來限制腳本僅從源服務器加載。

Cross-Origin-Embedder-Policy

啟用 COEP 頭可能會阻止那些未充分配置授權的跨源資源。這一機制作為一種安全措施，可以防范未授權的資源加載和跨源攻擊的潛在風險。

該頭設置方法如下:

Cross-Origin-Embedder-Policy: unsafe-none | require-corp | credentialless

圖片

COEP 指令解釋

• Unsafe-none：此默認值允許文檔在不需要通過 CORS 協議或 Cross-Origin-Resource-Policy 頭顯式授權的情況下獲取跨源資源。
• Require-corp：此值確保文檔只能加載來自相同源的資源，或那些顯式標記為可從其他源加載的資源。如果跨源資源支持 CORS，則必須使用跨源屬性或 Cross-Origin-Resource-Policy 頭進行加載，以避免被 COEP 阻止。
• Credentialless：當發出 no-cors 的跨源請求時，請求中不包含諸如 cookies 等憑證，響應中也會忽略這些憑證。響應被允許在無明確授權的情況下進行，但必須遵循 Cross-Origin-Resource-Policy 頭的規定。對于導航響應，其行為與 require-corp 模式相似，即需要 Cross-Origin-Resource-Policy 響應頭。

要有效地實現 COEP 頭，必須仔細考慮跨源資源的配置及其權限。遵循最佳實踐并確保必要的策略正確設置，允許期望的跨源資源交互，同時阻止未授權的訪問，這是至關重要的。

Cross-Origin-Resource-Policy

跨源資源策略（CORP）是一種通過 Cross-Origin-Resource-Policy HTTP 頭啟用的保護機制。它可以保護網站和應用免受來自其他源的特定請求，降低投機性旁路攻擊（例如 Spectre）和跨站腳本包含攻擊的風險。

CORP 頭特別有效于緩解與跨源攻擊相關的風險，其中攻擊者試圖利用不同源中的漏洞來獲取未授權訪問或提取敏感信息。通過限制僅信任的源可以包含資源，CORP 頭防止惡意行為者在其上下文中執行惡意代碼。

該頭設置方法如下:

Cross-Origin-Resource-Policy: same-site | same-origin | cross-origin

CORS 頭部使用

• same-site：只有來自同一站點的請求才能訪問該資源，這由跨源資源策略（CORP）強制執行。
• same-origin：該資源只能被來自同一源（協議 + 主機 + 端口）的請求訪問，這由跨源資源策略（CORP）定義。
• cross-origin：來自任何源的請求，無論是同一站點還是跨站源，都可以根據跨源資源策略訪問該資源。

正確配置 CORP 頭可以確保只有經過授權和信任的源才能包含資源。通過實施這一頭部，Web 應用可以顯著降低潛在的攻擊面，并增強整體安全性。

Cross-Origin-Opener-Policy

跨源開啟者策略（COOP）HTTP 頭使我們能夠防止頂級文檔與跨源文檔共享瀏覽上下文組。

HTTP 跨源開啟者策略（COOP）響應頭的實施是一個重要的安全措施，確保頂級文檔與跨源文檔保持嚴格的隔離，從而阻止未經授權的瀏覽上下文組共享，防止抄襲或非法復制。它與跨源嵌入策略（COEP）和跨源資源策略（CORP）頭一起工作，是一項重要的安全防護措施。

此頭部在防止如 Spectre 等攻擊中起著至關重要的作用，這些攻擊可能突破同源策略（SOP）為同一瀏覽上下文組中的資源所建立的安全邊界。

該頭設置方法如下:

Cross-Origin-Opener-Policy: unsafe-none
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cross-Origin-Opener-Policy: same-origin

圖片

COOP 頭部指令解釋

• unsafe-none：這是默認行為，文檔可以被添加到其開啟者的瀏覽上下文組，除非它有一個 same-origin 或 same-origin-allow-popups 的 COOP 頭。
• same-origin-allow-popups：保留對新打開的窗口或標簽頁的引用，這些窗口或標簽頁要么不設置 COOP，要么通過設置 COOP 頭為 unsafe-none 來選擇退出隔離。
• same-origin：這將瀏覽上下文僅限于同源文檔，防止跨源文檔在同一上下文中加載。

跨源開啟者策略（COOP）頭通過防止跨源文檔與頂級文檔共享瀏覽上下文組來提供保護。它與相關的頭部一起工作，增強 Web 瀏覽安全性，并減輕與跨源攻擊相關的風險。

Set-Cookie

Set-Cookie HTTP 響應頭用于將 cookie 從服務器發送到用戶的瀏覽器，從而允許服務器在未來的請求中存儲信息。通過在響應中包含多個 Set-Cookie 頭，可以發送多個 cookie。

雖然 Set-Cookie 頭本身并不被歸類為安全頭部，但其安全屬性/標志對于確保安全的會話管理和防止潛在的漏洞至關重要。

該頭設置方法如下:

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<number>
Set-Cookie: <cookie-name>=<cookie-value>; Partitioned
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None; Secure
// Multiple attributes are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly

Set-Cookie 頭部屬性解釋

• max-age=<number>Max-Age 屬性指定 cookie 在多少秒后過期。值為零或負數會立即使 cookie 過期。如果同時設置了 Expires 和 Max-Age，則以 Max-Age 為準。
• HttpOnlyHttpOnly 屬性限制 JavaScript 通過 Document.cookie 屬性訪問 cookie。然而，它并不阻止通過 JavaScript 發起的請求（如 XMLHttpRequest 或 fetch）發送該 cookie。此屬性有助于減輕跨站腳本（XSS）攻擊的風險。
• SecureSecure 屬性確保 cookie 只有在通過 HTTPS 協議的請求中才會被發送（除非是本地服務器）。這樣可以有效防止中間人攻擊。
• SameSite

Strict：當 SameSite 屬性設置為 "Strict" 時，cookie 僅會在請求來源于設置該 cookie 的相同站點時發送。來自第三方網站的跨站請求不會攜帶該 cookie。這有效地避免了 CSRF 攻擊，攻擊者無法利用用戶的瀏覽器在其他站點上執行未經授權的操作。

Lax：當 SameSite 屬性設置為 "Lax" 時，cookie 可以在跨站請求中發送，但僅限于頂級導航（例如點擊鏈接）。然而，由第三方資源（如圖片或腳本）發起的跨站請求將不會攜帶該 cookie。這樣在安全性和可用性之間達到了良好的平衡。

None：將 SameSite 屬性設置為 "None" 允許 cookie 在所有跨站請求中發送，通常在需要跨源身份驗證或其他功能的場景下使用。Web 管理員應謹慎使用該屬性，因為它可能會導致安全漏洞，尤其是當 cookie 包含敏感數據時。

• PartitionedSameSite 屬性可以設置為 "None"，表示 cookie 應使用分區存儲進行存儲。

持久性 Cookie（永久性 Cookie）

持久性 Cookie 在客戶端關閉時不會被刪除。它們會在 Expires 屬性定義的具體日期或在 Max-Age 屬性指定的時間后被刪除。

示例:

// 兩個請求都來自安全來源（HTTPS）
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// 因為缺少 Secure 屬性而被拒絕
Set-Cookie: __Secure-id=1

// 因為缺少 Path=/ 屬性而被拒絕
Set-Cookie: __Host-id=1; Secure

// 因為設置了 Domain 而被拒絕
Set-Cookie: __Host-id=1; Secure; Path=/; Domain=example.com

以 __Secure- 或 __Host- 為前綴的 cookie 有特殊的安全限制。只有當它們通過安全（HTTPS）源設置并且具有 secure 屬性時，才能使用。

此外，帶有 __Host- 前綴的 cookie 必須具有路徑 /（即主機下的任何路徑），且不能包含 Domain 屬性。這些額外的約束有助于防止某些類型的安全漏洞。

圖片

Strict-Transport-Security (HSTS)

HTTP 嚴格傳輸安全（HSTS）響應頭指示瀏覽器僅通過 HTTPS 訪問網站，自動將任何 HTTP 請求轉換為 HTTPS，從而提高安全性。

網站使用 HTTP 嚴格傳輸安全（HSTS）響應頭強制執行安全通信，指示瀏覽器通過 HTTPS 而非 HTTP 訪問網站。這通過為 HSTS 設置較長的有效期、包括子域名以及啟用預加載來確保安全的瀏覽體驗。

該頭設置方法如下:

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains; preload

圖片

HSTS 頭部指令解釋

• max-age=<expire-time>指定的時長（以秒為單位）決定瀏覽器應該記住該站點只能通過 HTTPS 訪問的時間。
• includeSubDomains通過提供此可選參數，該規則也擴展到包括所有網站子域名。
• Preload使用 preload 時，必須將 max-age 指令設置為至少 31536000（1 年），并包括 includeSubDomains 指令。所有當前和未來的子域名將強制啟用 HTTPS，且該配置有效期為一年（max-age=31536000）。這可以防止只能通過 HTTP 提供的頁面或子域的訪問。

設置參考:

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

所有當前和未來的子域名將強制啟用 HTTPS，且該配置有效期為一年（max-age=31536000）。這可以防止只能通過 HTTP 提供的頁面或子域的訪問。

另一個設置參考:

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

在此示例中，max-age 設置為 2 年，并附加了 "preload" 后綴。包括 "preload" 對于將站點添加到主要瀏覽器（如 Chromium、Edge 和 Firefox）的 HSTS 預加載列表中是必需的。

然而，在實施 HSTS 之前，必須徹底了解該頭部的工作原理。不當的配置或 SSL/TLS 證書問題可能會導致合法用戶無法訪問網站。例如，如果 HSTS 頭部設置了較長的有效期，并且 SSL/TLS 證書過期或被撤銷，用戶可能會被鎖定，直到 HSTS 過期。這就是為什么在啟用 HSTS 時需要確保 SSL/TLS 證書始終有效，并且沒有中斷服務的原因。

如圖:

圖片

Referrer-Policy

Referrer-Policy HTTP 頭部控制通過 Referer 頭部指定的請求中包含的引用信息的范圍。除了通過 HTTP 頭部設置此策略外，它還可以在 HTML 中進行配置。

Referrer-Policy HTTP 頭部管理通過 Referer 頭部包含的引用信息的級別。該頭部允許控制披露的詳細程度，如來源、路徑和查詢字符串。

該頭設置方法如下:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Referrer-Policy 頭部指令解釋

• No-referrer實施此配置將排除 Referer 頭部，確保發送的請求不包含任何引用信息。
• No-referrer-when-downgrade當協議安全級別保持不變或提高時（例如，HTTP 到 HTTP、HTTP 到 HTTPS、HTTPS 到 HTTPS），Referer 頭部包含來源、路徑和查詢字符串。然而，當請求到達較不安全的目標時（例如，HTTPS 到 HTTP、HTTPS 到 file），將省略 Referer 頭部。
• Origin在這種情況下，Referer 頭部只發送來源。例如，如果文檔位于 https://example.com/page.html，發送的引用信息將是 https://example.com/。
• Origin-when-cross-origin對于同源請求和相同協議級別的請求（例如，HTTP 到 HTTP、HTTPS 到 HTTPS），Referer 頭部將包括來源、路徑和查詢字符串。對于跨域請求和請求到較不安全的目標（例如，HTTPS 到 HTTP），只會發送來源。
• Same-origin對于同源請求，Referer 頭部包括來源、路徑和查詢字符串。然而，對于跨域請求，不會發送 Referer 頭部。
• Strict-origin在協議安全級別保持不變的情況下（例如，HTTPS 到 HTTPS），Referer 頭部僅發送來源。然而，當訪問較不安全的目標時（例如，HTTPS 到 HTTP），Referer 頭部不會被包含。
• Strict-origin-cross-when-origin當發起同源請求時，Referer 頭部包括來源、路徑和查詢字符串。對于跨域請求，只有在協議安全級別不變時（例如，HTTPS 到 HTTPS），Referer 頭部才會僅包含來源。然而，Referer 頭部不會發送到較不安全的目標（例如，HTTPS 到 HTTP）。
• Unsafe-URL在所有類型的請求中，無論安全性如何，Referer 頭部都包括來源、路徑和查詢字符串。

舉例:

Referrer-Policy: no-referrer, strict-origin-when-cross-origin

在上述場景中，僅在瀏覽器不支持 strict-origin-when-cross-origin 策略時，才會使用 no-referrer 策略。

Referrer-Policy 頭部使網站所有者能夠管理在請求中共享的引用信息的級別。為了確保不同瀏覽器版本的一致和安全行為，建議在所有請求中都包含此頭部，以強制執行所需的引用策略。

X-Content-Type-Options

Web 服務器使用 X-Content-Type-Options 頭部來指定聲明的 Content-Type 應該被遵循而不是更改。它有助于防止 MIME 類型嗅探，表明指定的 MIME 類型是故意設置的，應該不被覆蓋。

在響應 HTTP 中包括 X-Content-Type-Options 頭部，是服務器用來向 web 瀏覽器傳達關于如何處理 Content-Type 頭部中指定的 MIME 類型的特定指令的一個關鍵安全措施。這是針對一種潛在的安全漏洞——MIME 類型混淆攻擊的預防措施。

Microsoft 在 IE 8 中引入了 X-Content-Type-Options 頭部，以防止內容嗅探并將非可執行的 MIME 類型轉換為可執行的 MIME 類型。其他瀏覽器也已采納此頭部，盡管它們的 MIME 嗅探算法可能不那么激進。

該頭用法如下:

X-Content-Type-Options: nosniff

X-Content-Type-Options 頭部指令解釋

nosniffX-Content-Type-Options 頭部會阻止請求，如果目標是樣式或腳本文件，并且聲明的 MIME 類型與預期的類型不匹配（樣式文件應為 text/css，腳本文件應為 JavaScript MIME 類型）。

實施 X-Content-Type-Options 頭部作為全面安全策略的一部分，能夠為 web 應用提供一層保護，防止瀏覽器對 MIME 類型的誤用或誤解。

X-Frame-Options

X-Frame-Options HTTP 響應頭部控制網頁是否可以在 frame 或 iframe 中顯示。它確保內容不會被嵌入到其他站點，幫助防止點擊劫持攻擊（click-jacking）。

X-Frame-Options 響應頭部作為一種安全措施，允許網站指定瀏覽器是否可以在 frame 或 iframe 中呈現其頁面。通過使用該頭部，網站可以防止點擊劫持攻擊，確保它們的內容不會未經授權地嵌入到其他網站中。

該頭設置方法如下:

X-Frame-Options: DENY
X-Frame-Options: SAMEORIGIN

X-Frame-Options 頭部指令解釋

• DENY: 無論該站點是否嘗試將頁面嵌入，都禁止頁面在任何框架中顯示。
• SAMEORIGIN: 如果 X-Frame-Options 頭部設置為 SAMEORIGIN，則只有在所有父框架具有與頁面相同的源時，頁面才可以在框架中顯示。
• ALLOW-FROM origin: 該指令已過時，現代瀏覽器不再支持。如果使用該指令，將與未包括該頭部的效果相同。建議使用 Content-Security-Policy HTTP 頭部中的 frame-ancestors 指令代替。

配置 Apache 發送 X-Frame-Options

要配置 Apache 實例以便為所有頁面發送 X-Frame-Options 頭部，可以將以下代碼添加到站點的配置中：

Header always sets X-Frame-Options "SAMEORIGIN"

此值確保 X-Frame-Options 頭部包含在所有頁面的響應中。

要配置 Apache 為所有頁面設置 X-Frame-Options 為 DENY，可以將以下代碼添加到站點的配置中：

Header set X-Frame-Options "DENY"

此配置確保 X-Frame-Options 頭部包含在所有頁面的響應中，指示瀏覽器在任何情況下都不在 HTML 框架中顯示頁面。

配置 Nginx 發送 X-Frame-Options

要配置 Nginx 發送 X-Frame-Options 頭部，可以將以下代碼添加到 Nginx 配置中的 http、server 或 location 塊中：

add_header X-Frame-Options SAMEORIGIN always;

此配置確保 X-Frame-Options 頭部包含在響應中，指示瀏覽器僅在源與頁面的源匹配時，允許頁面在框架中顯示。

配置 HAProxy 發送 X-Frame-Options

要配置 HAProxy 以便它發送 X-Frame-Options 頭部，可以將以下行添加到 HAProxy 配置中的 front-end、listen 或 backend 部分：

http-response set-header X-Frame-Options SAMEORIGIN

這會將 X-Frame-Options 頭部設置為 SAMEORIGIN，表示頁面只有在源與頁面源匹配時才可以顯示在框架中。

X-XSS-Protection

X-XSS-Protection 頭部是一個由 Internet Explorer、Chrome 和 Safari 瀏覽器支持的安全功能，旨在防止反射型跨站腳本（XSS）攻擊。然而，在現代瀏覽器中，如果已啟用強大的內容安全策略（CSP）以禁用不安全的內聯 JavaScript，通常就不再需要使用該頭部。

HTTP X-XSS-Protection 響應頭是 Internet Explorer、Chrome 和 Safari 瀏覽器中的一項安全功能。當網頁被識別為易受反射型跨站腳本（XSS）攻擊時，該功能會阻止網頁的加載。

該頭的使用方法如下:

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>

X-XSS-Protection 頭部常見值解釋

• 0: 禁用 XSS 過濾器。
• 1: 啟用瀏覽器內置的 XSS 過濾器。如果檢測到 XSS 攻擊，瀏覽器會嘗試通過移除不安全的部分來凈化頁面。
• 1; mode=block: 啟用瀏覽器的 XSS 過濾器。如果檢測到 XSS 攻擊，瀏覽器會阻止頁面渲染，而不是嘗試凈化頁面。
• 1; report=<reporting-URI>（僅限 Chromium）: 啟用瀏覽器的 XSS 過濾器。如果檢測到 XSS 攻擊，瀏覽器會凈化頁面并使用 Content-Security-Policy（CSP）中的 report-uri 指令報告違規情況。

雖然 X-XSS-Protection 頭部可以保護尚不支持內容安全策略（CSP）的較舊瀏覽器的用戶，但需要注意的是，在某些情況下，該頭部可能會在本應安全的網站中引入 XSS 漏洞。因此，不能僅依賴此頭部作為唯一的防護措施。必須謹慎使用，因為單靠該頭部可能不會提供全面的保護，且在某些情況下可能會無意中引入 XSS 漏洞。

圖片

X-Permitted-Cross-Domain-Policies

X-Permitted-Cross-Domain-Policies（XPCDP）頭是一個與安全相關的 HTTP 響應頭，允許網站管理員定義跨域通信的策略。它用于控制瀏覽器如何處理跨域請求，如加載資源或在不同域之間發起請求。

XPCDP 頭指定了一個策略文件的位置，該文件定義了跨域請求的權限。該策略文件通常是一個 XML 文檔，列出了跨域通信的規則和權限。該頭的值可以設置為以下選項之一：

X-Permitted-Cross-Domain-Policies: none

None：表示不允許任何跨域訪問，任何嘗試都會被阻止。

Master-only：允許訪問同一域上定義的主策略文件。

By-content-type：根據請求的資源的內容類型，允許訪問其他域。

By-FTP filename：根據請求資源的文件名，允許訪問其他域。

All：當頭設置為“all”時，網站允許跨域交互，包括跨源請求和腳本包含。

通過實現帶有適當策略文件的 X-Permitted-Cross-Domain-Policies 頭，網站管理員可以控制和限制網站與其他域的交互，從而幫助減少潛在的安全風險，如跨站腳本（XSS）攻擊或跨域數據泄露。

需要注意的是，并非所有瀏覽器都廣泛支持 XPCDP 頭，因此其有效性可能會在不同的客戶端環境中有所不同。不過，它為兼容的瀏覽器提供了一個額外的跨域通信安全控制層。

圖片

Cache-Control

Cache-Control 頭用于 HTTP 響應中，指定緩存指令，告訴客戶端（如網頁瀏覽器）及中間緩存如何處理和緩存響應。它允許網站管理員控制資源在客戶端的緩存行為，從而提高網站性能。

Cache-Control: public, max-age=3600

此頭告知客戶端和中間緩存實體，響應可以公開緩存，并在 3600 秒（1 小時）內從緩存中提供，而不需要重新驗證。Cache-Control 頭可以包含多種指令，定義緩存規則。

解釋 Cache-Control 頭的指令：

• Public：表示客戶端和中間緩存都可以緩存該響應。
• Private：指定響應僅針對特定用戶，并且不應被中間緩存緩存。
• No-cache：表示響應應在第一次重新驗證服務器后，才可以從緩存中提供。
• No-store：指示客戶端和中間緩存在任何情況下都不應存儲響應的緩存副本。
• Max-age=<seconds>：指定響應可以在緩存中保留的新鮮時間（以秒為單位），在此時間內無需重新驗證。
• S-maxage=<seconds>：與 max-age 類似，但專門用于共享或中間緩存。
• Must-revalidate：客戶端在再次使用緩存響應之前，必須先重新驗證緩存。
• Proxy-revalidate：與 must-revalidate 相似，但專門適用于中間緩存。

通過正確配置 Cache-Control 頭，網站管理員可以控制瀏覽器和緩存如何處理資源的緩存。這可以幫助提高網站性能、減少服務器負載，并確保用戶獲取到最新的內容。然而，如果 Cache-Control 頭配置錯誤，可能會導致緩存欺騙攻擊。

X-Powered-By

X-Powered-By 頭揭示了網頁服務器所使用的技術，這可能使其暴露于潛在的安全威脅中。攻擊者可以利用這些信息來識別特定的技術，并可能利用與這些技術相關的已知漏洞。

需要注意的是，通過 X-Powered-By 頭公開服務器信息，可能會使攻擊者更容易定位并攻擊服務器。通過移除或修改該頭，網頁應用程序可以減少攻擊面，使潛在的攻擊者更難識別并利用漏洞。

X-Powered-By: Nginx

為了增強網頁應用的安全性，建議避免在 X-Powered-By 頭中包含敏感信息，并遵循服務器配置和加固的最佳實踐。

Public-Key-Pins(HPKP)

公鑰固定擴展（HPKP）曾是一種安全機制，指示網頁客戶端將特定的加密公鑰與特定的網頁服務器關聯，從而幫助減少利用偽造證書進行中間人攻擊（MITM）的風險。然而，該頭部已被棄用，不再推薦使用。

總結

安全頭部對于保護網頁應用程序免受各種漏洞的攻擊至關重要，特別是在防范跨站腳本攻擊（XSS）方面。

通過利用這些 HTTP 安全頭部，如內容安全策略（CSP）、嚴格傳輸安全（HSTS）以及上述討論的其他相關安全措施，我們可以加強網站防御，避免客戶端腳本的惡意注入。通過優先考慮并正確配置這些頭部，可以保護用戶的敏感信息，并確保安全的瀏覽體驗。