進一步瞭解有助於確保網站安全,並快速查詢最重要的詳細資料。
本文列出哪些最重要的安全性標頭,可用來保護 你的網站透過這項功能瞭解網路式安全防護功能,並學習如何 導入這些規則,並當做日後提醒的參考。
- 對於處理敏感使用者資料的網站,建議採用下列安全性標頭:
- 內容安全政策 (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';
建議用途
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 範例。 請使用開發人員工具查看廣告素材的使用方式。
支援的瀏覽器
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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
建議用途
-
強制將受信任的類型用於危險的 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 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>注意:</b>如要限制允許的信任類型政策名稱,您可以設定額外的<code>信任類型</code>指令 (例如 <code>trusted-types myPolicy</code>)。不過,這並非必要條件。</aside>
-
定義政策
政策:
// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
// Name and create a policy
const policy = trustedTypes.createPolicy('escapePolicy', {
createHTML: str => {
return str.replace(/\/g, '>');
}
});
}
-
套用政策
將資料寫入 DOM 時請使用以下政策:
// Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
在 require-trusted-types-for 'script'
中,使用信任的類型是
才能正常運作搭配字串使用任何危險 DOM API,會導致
錯誤。
支援的瀏覽器
瞭解詳情
X-Content-Type-Options
向您的網域提供惡意 HTML 文件時 (例如, 上傳至相片服務的圖片包含有效的 HTML 標記),有些瀏覽器 會將該文件視為使用中的文件,並允許該文件在 進而導致跨網站指令碼攻擊 錯誤。
X-Content-Type-Options: nosniff
會指示瀏覽器
MIME 類型 (位於
特定回應的 Content-Type
標頭正確無誤。這個標頭是
建議用於所有資源。
使用範例
X-Content-Type-Options: nosniff
建議用途
建議用於提供 X-Content-Type-Options: nosniff
資源的所有資源
伺服器和正確的 Content-Type
標頭。
![X-Content-Type-Options:nosniff](https://web.developers.google.cn/static/articles/security-headers/image/x-content-type-options-n-7088b3ce0282f.png?authuser=5&hl=zh-tw)
透過文件 HTML 傳送標頭的範例
X-Content-Type-Options: nosniff Content-Type: text/html; charset=utf-8
支援的瀏覽器
瞭解詳情
X-Frame-選項
如果惡意網站可以將您的網站嵌入為 iframe,或許就能派上用場 攻擊者透過 點擊劫持。另外,在某些 案件 Spectre-type 攻擊 惡意網站有機會得知內嵌文件的內容。
X-Frame-Options
表示是否允許瀏覽器顯示
<frame>
、<iframe>
、<embed>
或 <object>
中的網頁。所有文件
建議傳送此標頭,指明廣告是否允許
嵌入其他文件中
使用範例
X-Frame-Options: DENY
建議用途
所有無法嵌入的文件都應使用 X-Frame-Options
標頭。
您可以嘗試以下設定對載入 iframe 造成以下影響:
示範。變更X-Frame-Options
下拉式選單,然後按一下「重新載入 iframe」按鈕。
防止其他網站嵌入您的網站
拒絕嵌入任何其他文件。
![X-Frame-Options:DENY](https://web.developers.google.cn/static/articles/security-headers/image/x-frame-options-deny-0729b63f3a2e.png?authuser=5&hl=zh-tw)
X-Frame-Options: DENY
防止網站嵌入任何跨來源網站
只允許嵌入相同來源的文件。
X-Frame-Options: SAMEORIGIN
支援的瀏覽器
瞭解詳情
跨來源資源政策 (CORP)
攻擊者可嵌入其他來源的資源,例如你的網站 利用網頁式跨網站 外洩
Cross-Origin-Resource-Policy
會指定
都可以載入標頭會採用以下三個值的其中之一:
same-origin
、same-site
和cross-origin
。所有資源
建議您傳送此標頭,指出它們是否允許
或來自其他網站的資料。
使用範例
Cross-Origin-Resource-Policy: same-origin
建議用途
建議「所有」資源都提供下列其中一項屬性 三個標題
您可以嘗試下列設定對以下設定的影響:
在這個這個Cross-Origin-Embedder-Policy: require-corp
環境
示範。變更
Cross-Origin-Resource-Policy 下拉式選單,然後點選 重新載入
iframe 或 重新載入圖片按鈕,看看效果如何。
允許載入資源 cross-origin
建議類似 CDN 的服務將 cross-origin
套用至資源
(因為這類頁面通常是由跨來源頁面載入),除非網頁上已經放送
透過 CORS 產生類似的效果
![Cross-Origin-Resource-Policy:cross-origin](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-365b98767bed6.png?authuser=5&hl=zh-tw)
Cross-Origin-Resource-Policy: cross-origin
限制從 same-origin
載入的資源
「same-origin
」應套用至只用於載入的資源
相同來源的頁面。應將這項做法套用至含有機密資料的資源
使用者相關資訊,或 API 的回應
只來自相同的來源
請注意,含有此標頭的資源仍可直接載入, 範例:在新的瀏覽器視窗中前往網址跨來源資源 政策只能保護資源無法嵌入其他網站。
![Cross-Origin-Resource-Policy:same-origin](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-27b9213f10fd2.png?authuser=5&hl=zh-tw)
Cross-Origin-Resource-Policy: same-origin
限制從 same-site
載入的資源
建議您將「same-site
」套用至與上述類似的資源
但適合由您網站的其他子網域載入。
![跨來源資源政策:相同網站](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-resource-pol-158905cfe6687.png?authuser=5&hl=zh-tw)
Cross-Origin-Resource-Policy: same-site
支援的瀏覽器
瞭解詳情
跨來源開發者政策 (COOP)
攻擊者的網站可以在彈出式視窗中開啟其他網站,以便學習 利用網頁式跨網站 外洩在某些情況下,這也能 入侵旁路攻擊,基於 Spectre。
Cross-Origin-Opener-Policy
標頭是文件隔離的方法
其來源為透過 window.open()
開啟的跨來源視窗本身,或
不含 rel="noopener"
的 target="_blank"
。因此,任何跨來源的發布商
的文件不會參照,也無法與
。
使用範例
Cross-Origin-Opener-Policy: same-origin-allow-popups
建議用途
您可以嘗試下列設定如何影響與 這個示範中的跨來源彈出式視窗。 變更兩個文件的「Cross-Origin-Opener-Policy」Cross-Origin-Opener-Policy下拉式選單 然後,按一下彈出式視窗,再點選開啟彈出式視窗按鈕,然後按一下傳送 postMessage,確認訊息是否已確實送達。
將文件從跨來源視窗隔離
設定 same-origin
可讓文件與跨來源隔離
文件視窗。
![Cross-Origin-Opener-Policy:same-origin](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-2d273fc0106eb.png?authuser=5&hl=zh-tw)
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](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-7311769f30905.png?authuser=5&hl=zh-tw)
Cross-Origin-Opener-Policy: same-origin-allow-popups
允許跨來源視窗參照文件
unsafe-none
是預設值,但您可以明確指出這會
文件可以透過跨來源視窗開啟,並保留共同存取權。
![Cross-Origin-Opener-Policy:secure-none](https://web.developers.google.cn/static/articles/security-headers/image/cross-origin-opener-polic-6542ad44c7cdc.png?authuser=5&hl=zh-tw)
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"
支援的瀏覽器
瞭解詳情
跨源資源共享 (CORS)
與本文中的其他項目不同,跨來源資源共享 (CORS) 標頭之外,也是要求和允許存取 跨來源資源
根據預設,瀏覽器會強制執行同源政策, 防止網頁存取跨來源資源。舉例來說 跨來源圖片已載入 (即使顯示於網頁上也是如此) 網頁中的 JavaScript 無法存取圖片的資料。 資源提供者可以放寬限制,並允許其他網站讀取 透過 CORS 選擇啟用。
使用範例
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
瞭解如何設定 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 秒快取
支援的瀏覽器
瞭解詳情
跨來源嵌入程式政策 (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 採用 require-corp
的單一值。傳送這個標頭即可
指示瀏覽器封鎖未透過
CORS 或 CORP。
![COEP 的運作方式](https://web.developers.google.cn/static/articles/security-headers/image/how-coep-works-28c183abab5d5.png?authuser=5&hl=zh-tw)
您可以嘗試以下設定對載入資源的 示範。變更 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"
支援的瀏覽器
瞭解詳情
HTTP 嚴格傳輸安全性 (HSTS)
透過一般 HTTP 連線的通訊不會加密,因此 將可存取的資料轉移至網路層級竊取器。
Strict-Transport-Security
標頭會告知瀏覽器不得載入
並改用 HTTPS完成設定後,瀏覽器就會使用
透過 HTTPS 取代 HTTP 來存取網域,且不進行重新導向
在標頭中定義的
使用範例
Strict-Transport-Security: max-age=31536000
建議用途
凡是從 HTTP 轉換為 HTTPS 的網站,都應以
Strict-Transport-Security
標頭。
Strict-Transport-Security: max-age=31536000
支援的瀏覽器