安全性標頭快速參考

進一步瞭解可確保網站安全性的標頭，以及如何快速查閱最重要的詳細資料。

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

本文列出最重要的安全標頭，可用於保護網站。您可以藉此瞭解網頁安全功能、如何在網站上實作這些功能，以及在需要提醒時做為參考。

如果網站會處理機密使用者資料，建議採用下列安全性標頭：
內容安全政策 (CSP)
信任類型
建議所有網站使用的安全性標頭：
X-Content-Type-Options
X-Frame-Options
跨源資源政策 (CORP)
跨源開啟器政策 (COOP)
HTTP 嚴格傳輸安全性 (HSTS)
具備進階功能的網站安全標頭：
跨源資源共享 (CORS)
跨源嵌入器政策 (COEP)
網路上的已知威脅
深入瞭解安全標頭前，請先瞭解網路上的已知威脅，以及使用這些安全標頭的原因。

深入瞭解安全標頭前，請先瞭解網路上的已知威脅，以及使用這些安全標頭的原因。

保護網站免於注入式安全漏洞

當應用程式處理的不受信任資料會影響其行為，且通常會導致執行攻擊者控制的指令碼時，就會發生注入安全漏洞。注入式錯誤最常導致的漏洞是跨網站指令碼攻擊 (XSS)，包括反映型 XSS、儲存型 XSS、DOM 型 XSS 和其他變體。

XSS 安全漏洞通常會讓攻擊者完全存取應用程式處理的使用者資料，以及同一網頁來源中託管的任何其他資訊。

傳統的防範注入攻擊措施包括：持續使用自動逸出 HTML 範本系統、避免使用危險的 JavaScript API，以及在獨立網域中代管檔案上傳作業，並清除使用者控制的 HTML，以正確處理使用者資料。

將網站與其他網站隔離

網頁的開放性允許網站以違反應用程式安全期望的方式互動。包括意外發出已驗證的要求，或將其他應用程式的資料嵌入攻擊者的文件中，讓攻擊者修改或讀取應用程式資料。

常見的網頁隔離機制破壞性安全漏洞包括點擊劫持、跨網站偽造要求 (CSRF)、跨網站指令碼置入 (XSSI) 和各種跨網站洩漏。

如果您對這些標頭感興趣，建議閱讀Post-Spectre Web Development。

安全地建構強大的網站

Spectre 會將載入相同瀏覽環境群組的任何資料，都視為可能可讀取，即使符合同源政策也一樣。瀏覽器會限制可能利用「跨來源隔離」特殊環境背後安全漏洞的功能。透過跨來源隔離，您可以使用 SharedArrayBuffer 等強大功能。

加密網站流量

如果應用程式未完整加密傳輸中的資料，竊聽攻擊者就能瞭解使用者與應用程式的互動，這時就會出現加密問題。

加密不足可能發生在下列情況：未使用 HTTPS、複合型內容、設定 Cookie 時未加入 Secure 屬性 (或 __Secure 前置字元)，或是 寬鬆的 CORS 驗證邏輯。

內容安全政策 (CSP)

跨網站指令碼攻擊 (XSS) 是一種攻擊，會利用網站安全漏洞注入並執行惡意指令碼。

Content-Security-Policy 可限制網頁可執行的指令碼，進一步防範跨網站指令碼攻擊。

建議您使用下列其中一種方法啟用嚴格 CSP：

  • 如果您在伺服器上算繪 HTML 網頁，請使用以 Nonce 為基礎的嚴格 CSP。
  • 如果 HTML 必須以靜態方式提供或快取 (例如單頁應用程式)，請使用以雜湊為基礎的嚴格 CSP。

使用範例：以隨機數為基礎的 CSP

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
如何使用 CSP

1. 使用以 Nonce 為基礎的嚴格 CSP {: #nonce-based-csp}

如果您在伺服器上算繪 HTML 網頁，請使用以 Nonce 為基礎的嚴格 CSP。

在伺服器端為每個要求產生新的指令碼 Nonce 值，並設定下列標頭：

伺服器設定檔

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

在 HTML 中，如要載入指令碼，請將所有 <script> 標記的 nonce 屬性設為相同的 {RANDOM1} 字串。

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google 相簿就是以 Nonce 為基礎的嚴格 CSP 範例。使用開發人員工具查看使用方式。

2. 使用以雜湊為準的嚴格 CSP {: #hash-based-csp}

如果 HTML 必須以靜態方式提供或快取，例如您要建構單頁應用程式，請使用以雜湊為基礎的嚴格 CSP。

伺服器設定檔

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

在 HTML 中，您必須內嵌指令碼，才能套用以雜湊為準的政策，因為大多數瀏覽器都不支援雜湊外部指令碼。

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

如要載入外部指令碼，請參閱「選項 B：以雜湊為準的 CSP 回應標頭」一節中的「動態載入來源指令碼」。

CSP 評估工具是評估 CSP 的好工具，同時也是以 Nonce 為基礎的嚴格 CSP 範例。使用開發人員工具查看使用方式。

支援的瀏覽器

CSP 的其他注意事項

瞭解詳情

Trusted Types

以 DOM 為基礎的 XSS 攻擊是指將惡意資料傳遞至支援動態程式碼執行的接收器，例如 eval() 或 .innerHTML。

Trusted Types 提供相關工具，協助您編寫、安全審查及維護應用程式，避免發生 DOM XSS 攻擊。可透過 CSP 啟用，並限制危險的 Web API 只接受特殊物件 (即「信任型別」)，預設確保 JavaScript 程式碼安全無虞。

如要建立這些物件，您可以定義安全性政策，確保在資料寫入 DOM 前，系統會持續套用安全性規則 (例如逸出或清除)。這些政策隨後會成為程式碼中唯一可能導入 DOM XSS 的位置。

使用範例

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
如何使用可信類型

  1. 針對危險的 DOM 接收器強制執行 Trusted Types CSP 和 Trusted Types 標頭： 

    Content-Security-Policy: require-trusted-types-for 'script'

    目前 'script' 是 require-trusted-types-for 指令唯一可接受的值。

    當然，您可以將 Trusted Types 與其他 CSP 指令合併：

將上述以 Nonce 為基礎的 CSP 與 Trusted Types 合併： 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>注意：</b>您可以設定額外的 <code>trusted-types</code> 指令 (例如 <code>trusted-types myPolicy</code>)，限制允許的「信任型別」政策名稱。不過，這並非必要步驟。</aside>


    
  
  1. 
    
    定義政策
    
    
    政策：
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    套用政策
    
    
    在將資料寫入 DOM 時使用政策：
    
    
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    
    
    使用 require-trusted-types-for 'script' 時，必須使用信任的型別。使用字串搭配任何危險的 DOM API 都會導致錯誤。
    
  
    3. 



支援的瀏覽器



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


瞭解詳情

X-Content-Type-Options

如果從您的網域提供惡意 HTML 文件 (例如上傳至相片服務的圖片含有有效的 HTML 標記)，部分瀏覽器會將其視為有效文件，並允許在應用程式環境中執行指令碼，導致跨網站指令碼攻擊。

X-Content-Type-Options: nosniff 會指示瀏覽器，特定回應的 Content-Type 標頭中設定的 MIME 類型正確無誤，藉此防止發生這類情況。建議所有資源都使用這個標頭。

使用範例

X-Content-Type-Options: nosniff
如何使用 X-Content-Type-Options

建議您為伺服器提供的所有資源，一併使用 X-Content-Type-Options: nosniff 和正確的 Content-Type 標頭。

X-Content-Type-Options: nosniff

隨文件 HTML 傳送的標頭範例

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

支援的瀏覽器

Browser Support

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

瞭解詳情

X-Frame-Options

如果惡意網站能將您的網站嵌入為 iframe，攻擊者就可能透過點擊劫持，讓使用者執行非預期的動作。此外，在某些情況下，惡意網站可能會利用 Spectre 類型的攻擊，瞭解嵌入文件的內容。

X-Frame-Options 表示瀏覽器是否可在 <frame>、<iframe>、<embed> 或 <object> 中顯示頁面。建議所有文件都傳送這個標頭，指出是否允許其他文件嵌入。

使用範例

X-Frame-Options: DENY
如何使用 X-Frame-Options

所有不適合嵌入的文件都應使用 X-Frame-Options 標頭。

您可以在這個示範中，試試下列設定對載入 iframe 的影響。變更 X-Frame-Options 下拉式選單，然後按一下「重新載入 iframe」按鈕。

防止其他網站嵌入您的網站

禁止任何其他文件嵌入。

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

防止任何跨來源網站嵌入您的網站

只允許同源文件嵌入。

X-Frame-Options: SAMEORIGIN

支援的瀏覽器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Source

瞭解詳情

跨來源資源政策 (CORP)

攻擊者可以嵌入來自其他來源的資源 (例如來自您的網站)，藉由利用網頁型跨網站洩漏來瞭解這些資源的相關資訊。

Cross-Origin-Resource-Policy 會指出可載入的網站組合，藉此降低這項風險。標頭會採用下列其中一個值：same-origin、same-site 和 cross-origin。建議所有資源都傳送這個標頭，指出是否允許其他網站載入。

使用範例

Cross-Origin-Resource-Policy: same-origin
如何使用 CORP

建議所有資源都使用下列其中一個標頭放送。

您可以嘗試下列設定，瞭解這些設定對 Cross-Origin-Embedder-Policy: require-corp 環境下資源載入的影響，請參閱這個示範。變更「Cross-Origin-Resource-Policy」下拉式選單，然後按一下「Reload the iframe」(重新載入 iframe) 或「Reload the image」(重新載入圖片) 按鈕，即可查看效果。

允許載入資源 cross-origin

建議 CDN 類型的服務對資源套用 cross-origin (因為這些資源通常是由跨來源網頁載入)，除非這些資源已透過 CORS 提供服務，因為這會產生類似效果。

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

限制從 same-origin 載入的資源

same-origin 應套用至僅供同源網頁載入的資源。如果資源包含使用者的私密資訊，或是 API 回應僅供同源呼叫，就應套用這項設定。

請注意，含有這個標頭的資源仍可直接載入，例如在新瀏覽器視窗中前往該網址。跨源資源政策只會保護資源，避免遭到其他網站嵌入。

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

限制從 same-site 載入的資源

建議對與上述類似的資源套用 same-site，但這些資源會由網站的其他子網域載入。

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

支援的瀏覽器

Browser Support

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Source

瞭解詳情

跨來源開啟者政策 (COOP)

攻擊者的網站可以在彈出式視窗中開啟其他網站，並利用網頁式跨網站洩漏漏洞，瞭解該網站的資訊。在某些情況下，這也可能導致基於 Spectre 的側通道攻擊遭到利用。

Cross-Origin-Opener-Policy 標頭可讓文件與透過 window.open() 或含有 target="_blank" 的連結開啟的跨來源視窗隔離，不必使用 rel="noopener"。因此，文件的任何跨來源開啟器都不會參照該文件，也無法與其互動。

使用範例

Cross-Origin-Opener-Policy: same-origin-allow-popups
如何使用 COOP

您可以在這個範例中，試試下列設定對跨來源彈出式視窗通訊的影響。 變更文件和彈出式視窗的「Cross-Origin-Opener-Policy」下拉式選單，然後按一下「Open a popup」按鈕，再按一下「Send a postMessage」，確認訊息是否確實送達。

將文件與跨來源視窗隔離

設定 same-origin 可將文件與跨來源文件視窗隔離。

Cross-Origin-Opener-Policy: same-origin 
Cross-Origin-Opener-Policy: same-origin

將文件與跨來源視窗隔離，但允許彈出式視窗

設定 same-origin-allow-popups 可讓文件保留對彈出式視窗的參照，除非這些視窗使用 same-origin 或 same-origin-allow-popups 設定 COOP。也就是說，same-origin-allow-popups 仍可保護文件，避免在以彈出式視窗開啟時遭到參照，但允許文件與自己的彈出式視窗通訊。

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

允許跨來源視窗參照文件

unsafe-none 是預設值，但您可以明確指出這份文件可由跨來源視窗開啟，並保留相互存取權。

Cross-Origin-Opener-Policy: unsafe-none 
Cross-Origin-Opener-Policy: unsafe-none

與 COOP 不相容的報表模式

當 COOP 阻止與 Reporting API 的跨視窗互動時，您會收到報表。

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP 也支援僅回報模式，因此您可以在不實際封鎖跨來源文件間通訊的情況下接收回報。

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

支援的瀏覽器

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

瞭解詳情

跨源資源共享 (CORS)

與本文中的其他項目不同，跨源資源共享 (CORS) 並非標頭，而是瀏覽器機制，可要求及允許存取跨源資源。

根據預設，瀏覽器會強制執行同源政策，防止網頁存取跨源資源。舉例來說，載入跨來源圖片時，即使圖片會顯示在網頁上，網頁上的 JavaScript 也無法存取圖片資料。資源供應商可以選擇啟用 CORS，放寬限制並允許其他網站讀取資源。

使用範例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
如何使用 CORS

在瞭解如何設定 CORS 之前，建議您先瞭解要求類型之間的差異。系統會根據要求詳細資料，將要求歸類為簡單要求或預檢要求。

簡易要求的條件：

  • 方法為 GET、HEAD 或 POST。
  • 自訂標題僅包含 Accept、Accept-Language、Content-Language 和 Content-Type。
  • Content-Type為 application/x-www-form-urlencoded、multipart/form-data 或 text/plain。

其他所有要求都會歸類為預檢要求。詳情請參閱 跨源資源共享 (CORS) - HTTP | MDN。

簡單要求

如果要求符合簡單要求條件，瀏覽器會傳送含有 Origin 標頭的跨來源要求，指出要求來源。

要求標頭範例

Get / HTTP/1.1
Origin: https://example.com

回應標頭範例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com 表示 https://example.com 可以存取回應內容。如果資源要讓任何網站都能讀取，可以將這個標頭設為 *，這樣一來，瀏覽器只會要求不使用憑證提出要求。
  • Access-Control-Allow-Credentials: true 表示允許攜帶憑證 (Cookie) 的要求載入資源。否則，即使要求來源出現在 Access-Control-Allow-Origin 標頭中，通過驗證的要求也會遭到拒絕。

您可以在這個示範中，嘗試簡單要求對 Cross-Origin-Embedder-Policy: require-corp 環境下載入資源的影響。勾選「跨源資源共享」核取方塊，然後按一下「重新載入圖片」按鈕，即可查看效果。

預檢要求

預檢要求會先傳送 OPTIONS 要求，檢查是否允許傳送後續要求。

要求標頭範例

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST 允許使用 POST 方法提出下列要求。
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type 可讓要求者在後續要求中設定 X-PINGOTHER 和 Content-Type HTTP 標頭。

回應標頭範例

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS 表示後續要求可透過 POST、GET 和 OPTIONS 方法提出。
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type 表示後續要求可以包含 X-PINGOTHER 和 Content-Type 標頭。
  • Access-Control-Max-Age: 86400 表示預檢要求結果可快取 86400 秒。

支援的瀏覽器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Source

瞭解詳情

跨來源嵌入程式政策 (COEP)

為降低以 Spectre 為基礎的攻擊竊取跨來源資源的可能性，系統預設會停用 SharedArrayBuffer 或 performance.measureUserAgentSpecificMemory() 等功能。

Cross-Origin-Embedder-Policy: require-corp 會禁止文件和工作站載入跨來源資源，例如圖片、指令碼、樣式表、iframe 等，除非這些資源明確選擇透過 CORS 或 CORP 標頭載入。COEP 可與 Cross-Origin-Opener-Policy 搭配使用，將文件加入跨來源隔離。

如要為文件啟用跨來源隔離，請使用 Cross-Origin-Embedder-Policy: require-corp。

使用範例

Cross-Origin-Embedder-Policy: require-corp
如何使用 COEP

使用範例

COEP 採用單一值 require-corp。傳送這個標頭後，您就能指示瀏覽器封鎖未透過 CORS 或 CORP 選擇加入的資源。

COEP 的運作方式

您可以嘗試下列設定，瞭解這些設定對這個示範載入資源的影響。變更「Cross-Origin-Embedder-Policy」下拉式選單、「Cross-Origin-Resource-Policy」下拉式選單、「Report Only」核取方塊等，瞭解這些設定對載入資源的影響。此外，請開啟報表端點的示範，確認系統是否會回報遭封鎖的資源。

啟用跨原始來源隔離

傳送 Cross-Origin-Embedder-Policy: require-corp 和 Cross-Origin-Opener-Policy: same-origin，啟用跨來源隔離。

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

回報與 COEP 不相容的資源

您可以使用 Reporting API 接收因 COEP 而遭到封鎖的資源報表。

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP 也支援僅回報模式，因此您可以在不實際封鎖載入資源的情況下接收報表。

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

支援的瀏覽器

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

瞭解詳情

HTTP 嚴格傳輸安全性 (HSTS)

透過純 HTTP 連線進行通訊時，資料不會經過加密，因此網路層級的竊聽者可以存取傳輸的資料。

Strict-Transport-Security 標頭會通知瀏覽器，一律不得使用 HTTP 載入網站，而是改用 HTTPS。設定完成後，瀏覽器會使用 HTTPS (而非 HTTP) 存取網域，且不會在標頭定義的期間內重新導向。

使用範例

Strict-Transport-Security: max-age=31536000
如何使用 HSTS

所有從 HTTP 遷移至 HTTPS 的網站，在收到 HTTP 要求時，都應以 Strict-Transport-Security 標頭回應。

Strict-Transport-Security: max-age=31536000

支援的瀏覽器

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Source

瞭解詳情

延伸閱讀