本頁面由 Cloud Translation API 翻譯而成。

安全性標頭快速參考

進一步瞭解有助於確保網站安全，並快速查詢最重要的詳細資料。

Eiji Kitamura

Artur Janc

Maud Nalpas

本文列出��最重要的安全性標頭，可用來保護你的網站透過這項功能瞭解網路式安全防護功能，並學習如何導入這些規則，並當做日後提醒的參考。

對於處理敏感使用者資料的網站，建議採用下列安全性標頭：: 內容安全政策 (CSP); 信任的類型
所有網站都建議使用下列安全性標頭：: X-Content-Type-Options; X 框架選項; 跨來源資源政策 (CORP); 跨來源開發者政策 (COOP); HTTP 嚴格傳輸安全性 (HSTS)
具備進階功能的網站安全性標頭：: 跨源資源共享 (CORS); 跨來源嵌入程式政策 (COEP)

網路上已知的威脅

在分析安全性標頭之前，請先瞭解網路上已知的威脅以及使用這些安全性標頭的原因

防止網站插入安全漏洞

當叢集處理了不受信任的資料時，就會出現插入安全漏洞可能會改變應用程式的行為，通常會導致由攻擊者控制的指令碼插入作業造成的最常見安全漏洞錯誤是跨網站指令碼 (XSS) 各種形式的樣本，包括 XSS, 已儲存 DOM 式 XSS 和和其他變化版本

一個 XSS 弱點通常可讓攻擊者取得使用者資料的完整存取權是由應用程式處理的資訊，以及同一網路中代管的任何其他資訊來源。

傳統的防禦插入防禦措施包括持續使用自動逸出功能 HTML 範本系統，避免使用危險的 JavaScript API 和 Google Cloud 控制台檔案上傳至獨立網域，並清除使用者控制的 HTML。

使用內容安全政策 (CSP) 控管哪些指令碼可以執行藉此降低插入作業的風險。
使用可信任的類型，強制對傳入危險的資料實施清理作業 JavaScript API。
使用 X-Content-Type-Options 可防止瀏覽器以錯誤方式解讀網站資源的 MIME 類型，執行指令碼

將您的網站與其他網站區隔開來

網站的開放性可讓網站以各種方式可能會違反應用程式的安全性期望這包括意外性對攻擊者的文件，允許攻擊者修改或讀取應用程式資料。

破壞網路隔離的常見安全漏洞包括 clickjacking、跨網站要求偽造 (CSRF)、跨網站包含指令碼 (XSSI) 和跨網站流失。

使用 X-Frame-Options 可防止惡意網站
使用跨來源資源政策 (CORP) 防止您網站的避免將資源納入跨來源網站。
使用跨來源開發者政策 (COOP) 來保護網站的來自惡意網站的互動視窗。
使用跨源資源共享 (CORS) 功能取自跨來源文件的網站資源。

光譜式網路開發計畫是很棒的書可以看看這些標題

安全地打造功能強大的網站

Spectre 會放置任何載入的資料歸入同一個瀏覽情境群組，且可能可讀取仍須遵守同源政策。瀏覽器限制功能能夠入侵特殊環境下的漏洞「跨來源隔離」。透過跨來源隔離使用 SharedArrayBuffer 等強大的功能。

使用跨來源嵌入政策 (COEP) 和 COOP：啟用跨來源隔離

加密網站流量

假如應用程式並未將傳遞資料，讓竊聽攻擊者瞭解使用者互動情形。

以下情況可能會導致加密不足：未使用 HTTPS、混合內容，在沒有 Secure 的情況下設定 Cookie 屬性 (或 __Secure) 前置字串)、或寬鬆 CORS 驗證邏輯。

使用 HTTP 嚴格傳輸安全性 (HSTS) 以一致的方式為來提交內容

內容安全政策 (CSP)

跨網站指令碼攻擊 (XSS) 是攻擊事件網站存在漏洞，使有心人士得以植入惡意指令碼執行狀態

Content-Security-Policy 提供的額外層可防範 XSS 攻擊，限制網頁可執行的指令碼。

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

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

使用範例：以 Nonce 為基礎的 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 中載入指令碼，請將所有指令碼的 nonce 屬性設為 <script> 標記設為同一個 {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 Evaluator 是一項實用的工具，評估 CSP，但同時要採用以 Nonce 為基礎的嚴格 CSP 範例。請使用開發人員工具查看廣告素材的使用方式。

支援的瀏覽器

* https: 是 Safari 的備用方案，unsafe-inline 則是非常舊版瀏覽器的備用方案。使用 https: 和 unsafe-inline 時，則無法降低政策安全性，因為支援 strict-dynamic 的瀏覽器會忽略這些政策。詳情請參閱「新增備用方案以支援 Safari 和舊版瀏覽器」。* Safari 尚未支援 strict-dynamic。不過，嚴格執行 CSP 的程序就如上例所示，比許可清單 CSP 更安全，也比沒有 CSP 更安全。即使在 Safari 中，嚴格 CSP 也能防止某些類型的 XSS 攻擊，因為存在 CSP 會禁止某些不安全的模式。

CSP 的其他注意事項

frame-ancestors敬上指令會保護您的網站免受點擊劫持，如果您允許嵌入您的網站。若您喜歡更簡單的解決方案，可以允許 X-Frame-Options 進行載入，但 frame-ancestors 會提供您的進階設定，僅允許特定來源做為嵌入器。
您可能曾使用 CSP 來確保網站的所有資源透過 HTTPS 載入。這有關聯性較低：現在，大多數瀏覽器複合型內容。
您也可以在僅限報表內設定 CSP 模式。
如果無法將 CSP 設為標頭伺服器端，也可以將其設為中繼標記之前。請注意，您無法將中繼標記使用僅限報表模式 (不過可能會改變)。

瞭解詳情

信任的類型

DOM 式 XSS 是將惡意資料傳遞至支援動態程式碼的接收器例如 eval() 或 .innerHTML

「Trusted Types」提供撰寫、安全性審查及維護的工具無需 DOM XSS您可透過 CSP 啟用，並將危險的網頁 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;

如何使用「Trusted Types」

建議用途

強制將受信任的類型用於危險的 DOM 接收器 CSP 和 Trusted Types 標頭：
```
Content-Security-Policy: require-trusted-types-for 'script'
```
目前唯一可接受的值是 'script' require-trusted-types-for 指令。

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

將上述 Nonce 為基礎的 CSP 與信任的類型合併：

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>信任類型</code>指令 (例如 <code>trusted-types myPolicy</code>)。不過，這並非必要條件。&lt;/aside&gt;


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

    注意： 您可以使用任意名稱來定義政策，除非您設定 trusted-types 指令來限制允許信任類型政策的名稱。
  
  
    套用政策
    將資料寫入 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，會導致
      錯誤。
  

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
瞭解詳情

  運用 Trusted 技術防範以 DOM 為基礎的跨網站指令碼安全漏洞
      類型
  CSP：require-trusted-types-for - HTTP |
      MDN
  CSP：Trust-types - HTTP |
      MDN
  Trusted Types 示範：開啟開發人員工具檢查器，並查看
    發生什麼事了？



X-Content-Type-Options

向您的網域提供惡意 HTML 文件時 (例如，
上傳至相片服務的圖片包含有效的 HTML 標記)，有些瀏覽器
會將該文件視為使用中的文件，並允許該文件在
進而導致跨網站指令碼攻擊
錯誤。

X-Content-Type-Options: nosniff 會指示瀏覽器
MIME 類型 (位於
特定回應的 Content-Type 標頭正確無誤。這個標頭是
建議用於所有資源。

使用範例
X-Content-Type-Options: nosniff


  
    
    如何使用 X-Content-Type-Options


    
      建議用途
建議用於提供 X-Content-Type-Options: nosniff 資源的所有資源
  伺服器和正確的 Content-Type 標頭。

透過文件 HTML 傳送標頭的範例
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  64
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  50
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  11
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame-選項

如果惡意網站可以將您的網站嵌入為 iframe，或許就能派上用場
攻擊者透過
點擊劫持。另外，在某些
案件 Spectre-type
攻擊
惡意網站有機會得知內嵌文件的內容。

X-Frame-Options 表示是否允許瀏覽器顯示
<frame>、<iframe>、<embed> 或 <object> 中的網頁。所有文件
建議傳送此標頭，指明廣告是否允許
嵌入其他文件中

注意： 如需更精細的控制項 (例如只允許特定來源嵌入文件)，請使用 CSP frame-ancestors 指令。

使用範例
X-Frame-Options: DENY


  
    
    如何使用 X-Frame-Options


    
      建議用途
所有無法嵌入的文件都應使用 X-Frame-Options 標頭。
您可以嘗試以下設定對載入 iframe 造成以下影響：
    示範。變更X-Frame-Options
  下拉式選單，然後按一下「重新載入 iframe」按鈕。
防止其他網站嵌入您的網站
拒絕嵌入任何其他文件。

X-Frame-Options: DENY

防止網站嵌入任何跨來源網站
只允許嵌入相同來源的文件。
X-Frame-Options: SAMEORIGIN

 系統預設會嵌入文件，因此網頁程式開發人員必須明確傳送 DENY 或 SAMEORIGIN，才能停止嵌入文件，並防範旁路攻擊。Chrome 團隊考慮改為預設封鎖文件嵌入功能，讓網站即使未明確設定標頭，仍能安全無虞。在這個新時代，文件需要明確選擇加入才能嵌入。
支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  X-Frame-Options - HTTP

    
  


跨來源資源政策 (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 下拉式選單，然後點選 重新載入
iframe 或 重新載入圖片按鈕，看看效果如何。

允許載入資源 cross-origin
建議類似 CDN 的服務將 cross-origin 套用至資源
  (因為這類頁面通常是由跨來源頁面載入)，除非網頁上已經放送
  透過 CORS 產生類似的效果

Cross-Origin-Resource-Policy: cross-origin

限制從 same-origin 載入的資源
「same-origin」應套用至只用於載入的資源
  相同來源的頁面。應將這項做法套用至含有機密資料的資源
  使用者相關資訊，或 API 的回應
  只來自相同的來源
請注意，含有此標頭的資源仍可直接載入，
  範例：在新的瀏覽器視窗中前往網址跨來源資源
  政策只能保護資源無法嵌入其他網站。

Cross-Origin-Resource-Policy: same-origin

限制從 same-site 載入的資源
建議您將「same-site」套用至與上述類似的資源
  但適合由您網站的其他子網域載入。

Cross-Origin-Resource-Policy: same-site

注意： 如要進一步瞭解「相同來源」和「相同網站」的差異，請參閱瞭解「相同網站」一文和「same-origin」。
支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  73
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  74
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  考慮部署跨來源資源政策
  讓網站「跨來源隔離」使用 COOP 和 COEP
  為何需要「跨來源隔離」提供多種強大功能

    
  


跨來源開發者政策 (COOP)

攻擊者的網站可以在彈出式視窗中開啟其他網站，以便學習
利用網頁式跨網站
外洩在某些情況下，這也能
入侵旁路攻擊，基於
Spectre。

Cross-Origin-Opener-Policy 標頭是文件隔離的方法
其來源���透過 window.open() 開啟的跨來源視窗本身，或
不含 rel="noopener" 的 target="_blank"。因此，任何跨來源的發布商
的文件不會參照，也無法與
。

使用範例
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    如何使用 COOP


    
      建議用途
您可以嘗試下列設定如何影響與
  這個示範中的跨來源彈出式視窗。
  變更兩個文件的「Cross-Origin-Opener-Policy」Cross-Origin-Opener-Policy下拉式選單
  然後，按一下彈出式視窗，再點選開啟彈出式視窗按鈕，然後按一下傳送
postMessage，確認訊息是否已確實送達。
將文件從跨來源視窗隔離
設定 same-origin 可讓文件與跨來源隔離
  文件視窗。

Cross-Origin-Opener-Policy: same-origin

將文件從跨來源視窗隔離，但允許彈出式視窗
設定 same-origin-allow-popups 可讓文件保留參照
  顯示彈出式視窗，除非使用者將 COOP 設定為 same-origin 或
  same-origin-allow-popups。這表示「same-origin-allow-popups」仍可
  防止在彈出式視窗開啟時參照文件，但
  可讓應用程式與自己的彈出式視窗通訊。


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

允許跨來源視窗參照文件
unsafe-none 是預設值，但您可以明確指出這會
  文件可以透過跨來源視窗開啟，並保留共同存取權。

 unsafe-none 為預設值表示網頁程式開發人員必須明確傳送 same-origin 或 same-origin-allow-popups，以防止網站受到旁路攻擊。
Cross-Origin-Opener-Policy: unsafe-none

注意： SharedArrayBuffer 或 performance.measureUserAgentSpecificMemory() 等功能預設為停用。部分瀏覽器允許您在「跨來源隔離」中使用結構定義，您必須設定 COOP 和 COEP 標頭。詳情請參閱「讓網站「跨來源隔離」使用 COOP 和 COEP
與 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"

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  為何需要「跨來源隔離」提供多種強大功能

    
  


跨源資源共享 (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 允許
    要求者在 HTTP 標頭中設定 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 秒快取

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  3.5
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  跨源資源共享 (CORS)
  跨源資源共享 (CORS) - HTTP |
      MDN

    
  


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

為了減少 Spectre-based 功能
攻擊
竊取跨來源資源，例如 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。


您可以嘗試以下設定對載入資源的 
    示範。變更
  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 不相容的資源
您可以透過報告接收 COEP 導致資源遭到封鎖的報告
  也能使用 Google Cloud CLI 或
Compute Engine API
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP 也支援報表專用模式，因此您無需實際取得報表
  禁止載入資源
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  83
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  79
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  15.2
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  讓網站「跨來源隔離」使用 COOP 和 COEP
  為何需要「跨來源隔離」提供多種強大功能
  跨來源隔離的啟用指南

    
  


HTTP 嚴格傳輸安全性 (HSTS)

透過一般 HTTP 連線的通訊不會加密，因此
將可存取的資料轉移至網路層級竊取器。

Strict-Transport-Security 標頭會告知瀏覽器不得載入
並改用 HTTPS完成設定後，瀏覽器就會使用
透過 HTTPS 取代 HTTP 來存取網域，且不進行重新導向
在標頭中定義的

使用範例
Strict-Transport-Security: max-age=31536000


  
    
    如何使用 HSTS


    
      建議用途
凡是從 HTTP 轉換為 HTTPS 的網站，都應以
  Strict-Transport-Security 標頭。

Strict-Transport-Security: max-age=31536000

支援的瀏覽器

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        瀏覽器支援
        
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  12
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  4
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  
  7
  
  
        
        
        資料來源
        
      
    
    
    
  
瞭解詳情

  嚴格傳輸安全性 -
      HTTP

    
  


延伸閱讀


Spectre 後的 Web 開發