混合內容
Baseline 廣泛可用 *
當一個網頁透過安全通道（例如 HTTPS）從安全源載入時，與 Web 伺服器的連線會被加密，因此可以防止竊聽和中間人攻擊的篡改。如果安全載入的網頁只包含同樣託管在安全源上的圖片、指令碼和其他資源，使用者可以確信整個頁面都是安全的，不會受到這類攻擊。
“混合內容”是指透過 HTTP 或其他不安全協議獲取資源的、已安全載入的網頁。這種網頁可能不安全，因為任何透過不安全方式傳送的資源都可能被攻擊者檢視，從而可能洩露敏感資訊，和/或被篡改。指令碼尤其危險，因為它們可以修改網頁的任何方面，但所有型別的資源都存在一定風險。例如，圖片可能被修改以向用戶提供錯誤或誤導性資訊，或者更改按鈕的顯示功能。
“混合下載”是指從安全上下文中啟動，但透過不安全連接獲取的資源下載。這些下載面臨與混合內容相同的風險：下載內容看起來來自安全源，但可能在傳輸過程中被篡改或被檢視。
你應該避免在你的網站中使用混合內容和混合下載！瀏覽器會透過自動將圖片、影片和音訊的混合內容請求從 HTTP 升級到 HTTPS 來減輕混合內容的風險，並阻止所有其他資源型別的 But would not allow insecure requests. They should also block mixed downloads by default.
混合內容型別
網頁中的混合內容分為兩類：“可升級內容”和“可阻止內容”。瀏覽器應該自動將可升級內容的請求從 HTTP 升級到 HTTPS，並阻止可阻止內容的請求。
這種方法可以確保安全上下文中的所有內容要麼透過安全通道載入，要麼被阻止，這比顯示混合安全和不安全內容對使用者來說更安全，並且比透過完全阻止不安全內容來破壞網頁更具干擾性。
注意： 規範的早期版本將混合內容分為“可阻止”和“可選可阻止”類別。
- 可阻止的內容型別，也稱為“活動混合內容”，是指可能修改網頁其他部分的內容，例如指令碼和樣式表。如果這些檔案被修改，潛在風險非常高，瀏覽器必須阻止它們。
- 可選可阻止的內容型別，也稱為“被動混合內容”，是指不能修改網頁中其他內容的檔案，例如圖片、影片和音訊檔案。允許這些檔案存在的潛在風險較低，因此瀏覽器可以選擇阻止或顯示它們，或者將決定權交給使用者。
構成“可升級內容”的資源型別集合源自“可選可阻止”的混合內容集合。預期是任何新的檔案型別都將被定義為可阻止內容，並且一些可升級內容在未來可能會變得可阻止。
可升級內容
可升級內容請求是指那些將不安全請求自動升級為安全請求的請求，透過將源方案從 `http` 更改為 `https`。遠端伺服器將響應資源，或者返回一個指示未找到的響應碼。
此類別中的資源型別是指那些如果阻止請求可能會破壞 Web 的大部分內容。這些目前對應於以前“可選可阻止”的混合內容型別，因為它們仍在某些網站上使用。
以下元素是可升級的（除非 URL 主機被指定為 IP 地址 — 請參閱下面的部分）
可阻止內容
可阻止內容定義為“所有不可升級的混合內容”。
這包括以下元素引起的 HTTP 請求（此列表並不詳盡）
<script>，其源透過 `src` 屬性設定。<link>，其源在 `href` 屬性中設定，並且包含樣式表。<iframe>，其源透過 `src` 屬性設定。fetch()請求。XMLHttpRequest請求。- CSS 中使用 `
` 值的所有情況（`@font-face`、`cursor`、`background-image` 等）。 <object>（`data` 屬性）。Navigator.sendBeacon（`url` 屬性）。<img>，其源透過 `srcset` 或 `` 設定。 - Web 字型
如果 URL 的主機是 IP 地址而不是域名，那麼原本會被升級的混合內容請求將被阻止。因此，`<img src="http://example.com/image.png">` 會被升級，但 `<img src="http://93.184.215.14/image.png">` 會被阻止。
混合內容請求示例
混合內容請求是來自 安全上下文的不安全資源請求。
以下示例演示了安全、不安全和混合內容請求。
- `http://insecure.com` 載入 `http://also.insecure.com` — 這不是混合內容請求，因為兩個源都不安全。
- `https://secure.com` 載入 `http://insecure.com` — 這是一個混合內容請求，因為不安全資源 `http://insecure.com` 被載入到安全上下文 `https://secure.com` 中。
- `http://insecure.com` 在 `<iframe>` 中載入 `https://secure.com`，而 `https://secure.com` 又載入 `http://also.insecure.com` — 將 `https://secure.com` 載入到 `http://insecure.com` 中不是混合內容請求（將安全上下文載入到不安全上下文中沒有限制）。但是將 `http://also.insecure.com` 載入到安全框架 `https://secure.com` 中是一個混合內容請求。
- `https://secure.com` 框架載入了一個 `data:` URL，該 URL 載入了 `http://insecure.com` — 這是一個混合內容請求，因為 `https://secure.com`（以及因此的 `data:`）是安全載入的，而 `http://insecure.com` 是不安全的。
混合上下文請求也可以來自外掛或工作執行緒等安全上下文，並且將以相同的方式被升級/阻止。
但請注意，從安全上下文導航到不安全的目標頂級瀏覽上下文的導航請求不被視為混合內容，因為它們會建立一個獨立於請求源的新上下文，該上下文要麼是安全的，要麼是不安全的。
載入本地提供的混合資源
本地資源被視為來自安全源，就像 HTTPS 源一樣。這包括 `file:` URL，以及從環回地址（如 `http://127.0.0.1/` 或 `https:///`）訪問的內容。
你可以從安全上下文載入這些檔案，你仍然會擁有一個安全上下文。但是，如果本地檔案透過 `http:` 載入了不安全資源，那將是一個混合內容請求。
載入本地內容的支援情況可以在 瀏覽器相容性 部分檢視。
混合下載
混合下載是指從安全上下文透過不安全連線下載資源。它們之所以有問題，原因與混合內容相同——內容可能被攻擊者攔截和/或篡改，並且使用者不清楚這可能會在一個安全網站上發生。
例如，以下程式碼定義了一個 <a> 元素，該元素可用於下載 `http://example.com/` 這個不安全源的頁面。如果這段程式碼在一個透過 HTTPS 提供的頁面中，儲存此連結將導致混合下載。
<a href="http://example.com/" download>Download</a>
預計瀏覽器會阻止混合下載，並且安全網站不應包含它們。
注意： 瀏覽器通常預設阻止混合下載，但會告知使用者風險並允許他們保留或放棄下載。
開發者控制檯
開發者控制檯在混合內容被升級或阻止時顯示警告。這些警告可用於除錯和修復網站中的混合內容問題。
下面的截圖顯示了 Firefox 中一張圖片被升級時的控制檯警告（Chrome 也有類似的警告）。
在仍然顯示“可選可阻止”內容的瀏覽器版本中，會使用一個圖示來指示顯示的內容中存在混合內容，並伴有控制檯警告。下面的截圖顯示了 Firefox 開始支援可升級混合內容時的圖示和控制檯警告。
修復混合內容問題
避免混合內容問題的最佳策略是全部以 HTTPS 的方式提供內容。
-
將您域中的所有內容都以 HTTPS 的方式提供。
-
將所有指向您域中資源的引用轉換為相對連結或 HTTPS 連結，包括下載連結。
-
如果使用其他網站的資源，請使用其 HTTPS 版本（如果可用）。
大多數網站都提供共享資源的 HTTPS 版本。通常最簡單的方法是將所有 `http://` 連結替換為 `https://`，然後使用 LinkChecker 等工具來驗證所有連結是否都能正常工作。
有多種方法可以驗證您的網站是否沒有混合內容，包括：
- 瀏覽您的網站，並在瀏覽器的 開發者控制檯 中查詢混合內容警告。
- 在瀏覽器中停用所有混合內容，並測試頁面是否按預期工作。這是 Safari 的預設設定，但大多數瀏覽器都支援某種阻止所有混合內容的機制（請參閱 相容性資料）。
- 使用桌面 Web 爬蟲（如 HTTPSChecker）或 CLI 工具（如 mcdetect）來遞迴檢查您的網站並查詢不安全內容的連結。
- 使用線上工具（如 Mixed Content Checker）來檢查您的網站。
規範
| 規範 |
|---|
| 混合內容 # 簡介 |
瀏覽器相容性
載入中…
另見
- CSP：`upgrade-insecure-requests` 會將所有請求升級到 HTTPS，包括可阻止的混合內容。