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

移除 XSLT，打造更安全的瀏覽器

Mason Freed

Dominik Röttsches

發布日期：2025 年 10 月 29 日

Chrome 打算淘汰並從瀏覽器中移除 XSLT。本文將詳細說明如何在 2026 年底移除前遷移程式碼。

Chromium 已正式淘汰 XSLT，包括 XSLTProcessor JavaScript API 和 XML 樣式表處理指令。我們預計在 155 版 (2026 年 11 月 17 日) 移除支援。Firefox 和 WebKit 專案也表示計畫從瀏覽器引擎中移除 XSLT。本文將提供相關歷史和背景資訊，說明我們如何移除 XSLT 來提升 Chrome 安全性，並提供遷移路徑，讓您在這些功能從瀏覽器中移除前完成遷移。

移除的項目為何？

瀏覽器中有兩個實作 XSLT 的 API，這兩個 API 都會移除：

XSLTProcessor 類別 (例如 new XSLTProcessor())。
XSLT 處理指令 (例如 <?xml-stylesheet … ?>)。

Chrome 時間軸

Chrome 方案如下：

Chrome 142 (2025 年 10 月 28 日)：在 Chrome 中新增早期警告控制台訊息。
Chrome 143 (2025 年 12 月 2 日)：正式淘汰 API，主控台和 Lighthouse 會開始顯示淘汰警告訊息。
Chrome 148 (2026 年 3 月 10 日 Canary 版)：Canary 版、開發人員版和 Beta 版開始預設停用 XSLT，做為早期預警。
Chrome 152 (2026 年 8 月 25 日)：來源試用 (OT) 和企業政策 (EP) 上線，供您測試。網站和企業可藉此在移除日期後繼續使用相關功能。
Chrome 155 (2026 年 11 月 17 日)：穩定版將停止運作 XSLT，適用於「原始碼試用」和「企業政策」參與者以外的所有使用者。**
Chrome 164 (2027 年 8 月 17 日)：來源試用和 Enterprise 政策停止運作。所有使用者都無法使用 XSLT。**

什麼是 XSLT？

XSLT (可延伸樣式表語言轉換) 是一種語言，用於轉換 XML 文件，通常會轉換成 HTML 等其他格式。這項工具會使用 XSLT 樣式表檔案定義轉換規則，以及包含做為輸入內容的資料的 XML 檔案。

在瀏覽器中，如果收到的 XML 檔案連結至 XSLT 樣式表，瀏覽器會使用該樣式表中的規則，重新排列、格式化及轉換原始 XML 資料，成為可供使用者算繪的結構化網頁 (通常是 HTML)。

舉例來說，XSLT 樣式表可以接受下列 XML 輸入：

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

以及這個 XSL 樣式表：

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:output method="html"/>
  <xsl:template match="/page/message">
    <body>
      <p>Message: <xsl:value-of select="."/></p>
    </body>
  </xsl:template>
</xsl:stylesheet>

並處理成下列 HTML，供瀏覽器顯示：HTML

<body>
  <p>Message: Hello World.</p>
</body>

除了上一個範例中顯示的 XSL 處理指令，還有 XSLTProcessor JavaScript API，可用於處理含有本機 XSLT 樣式表的本機 XML 文件。

XSLT 歷史

全球資訊網協會 (W3C) 於 1999 年 11 月 16 日建議使用 XSLT，將 XML 文件轉換為其他格式，最常見的是轉換為 HTML，以便在網頁瀏覽器中顯示。在正式的 1.0 建議發布前，Microsoft 率先根據 1999 年 3 月發布的 Internet Explorer 5.0 中的 W3C 工作草案，推出專屬實作項目。Mozilla 遵循官方標準，於 2000 年底在 Netscape 6 中實作原生 XSLT 1.0 支援。其他主要瀏覽器 (包括 Safari、Opera 和後來的 Chrome) 也納入了原生 XSLT 1.0 處理器，因此在 2000 年代初期，用戶端 XML 到 HTML 的轉換成為可行的網路技術。

XSLT 語言本身也不斷演進，2007 年發布 XSLT 2.0，2017 年發布 XSLT 3.0，其中導入了功能強大的功能，例如規則運算式、改良的資料型別，以及處理 JSON 的能力。但瀏覽器支援卻停滯不前。目前，所有主要網頁瀏覽器引擎都只原生支援 1999 年推出的原始 XSLT 1.0。由於缺乏進展，加上 JSON 做為連線格式的使用率提升，以及 JavaScript 程式庫和架構 (例如 jQuery、React 和 Vue.js) 提供更彈性且強大的 DOM 操作和範本功能，導致用戶端 XSLT 的使用率大幅下降。在網頁瀏覽器中，這些以 JavaScript 為基礎的技術已大幅取代 Flash 的角色。

為什麼需要移除 XSLT？

網頁瀏覽器持續納入 XSLT 1.0，會帶來重大且不必要的安全風險。處理這些轉換的底層程式庫 (例如 Chromium 瀏覽器使用的 libxslt) 是複雜且老舊的 C/C++ 程式碼集。這類程式碼極易發生記憶體安全漏洞，例如緩衝區溢位，進而導致任意程式碼執行。舉例來說，安全稽核和錯誤追蹤工具已多次在這些剖析器中發現嚴重程度高的安全漏洞 (例如 CVE-2025-7425 和 CVE-2022-22834 (均位於 libxslt 中)。由於用戶端 XSLT 現在是很少使用的利基功能，這些程式庫的維護和安全審查遠少於核心 JavaScript 引擎，但它們代表處理不受信任的網頁內容時，直接且強大的攻擊面。事實上，XSLT 是近期幾起備受關注的安全性攻擊事件的來源，持續對瀏覽器使用者造成風險。維護這項脆弱的舊版功能會帶來安全風險，遠遠超過其有限的現代實用性。

此外，用戶端 XSLT 的原始用途是將資料轉換為可轉譯的 HTML，但現在已有更安全、更符合人體工學且維護良好的 JavaScript API 取代。現代網頁開發作業會使用 Fetch API 等工具擷取資料 (通常是 JSON)，並使用 DOMParser API 將 XML 或 HTML 字串安全地剖析為瀏覽器安全 JavaScript 沙箱中的 DOM 結構。React、Vue 和 Svelte 等架構會有效率地安全管理這項資料的算繪作業。這個現代化工具鍊正在積極開發中，並受益於 JavaScript 引擎的大量安全投資，幾乎所有網頁開發人員目前都使用這個工具鍊。事實上，目前只有約 0.02% 的網頁載入會使用 XSLT，而使用 XSLT 處理指令的網頁則不到 0.001%。

這項行動不只適用於 Chrome 或 Chromium，其他兩大瀏覽器引擎也支援從網頁平台移除 XSLT：WebKit、Gecko。

基於上述原因，淘汰及移除 XSLT 可減少所有使用者的瀏覽器攻擊面、簡化網頁平台，並讓工程資源專注於保護實際為現代網路提供動力的技術，同時不會造成開發人員實際損失任何功能。

提升 XML 剖析安全性

與 libxslt 中的嚴重安全問題類似，最近有人回報 libxml2 存在嚴重安全問題，而 Chromium 會使用 libxml2 剖析、序列化及測試 XML 的格式是否正確。為解決 Chromium 中 XML 剖析的未來安全性問題，我們計畫逐步淘汰 libxml2 的使用，並以 Rust 編寫的記憶體安全 XML 剖析程式庫取代 XML 剖析。重要事項：我們不會從瀏覽器中移除 XML，只會考慮移除 XSLT。我們希望確保網頁開發人員完全不會察覺 libxml2 遭到取代。

如何遷移

您可以選擇其他移轉路徑。

JSON

如果網站完全以 XML 和 XSL 建構，就沒有一體適用的轉換方式。遷移選項包括將 XSLT 處理管道移至伺服器端，並將算繪的 HTML 傳送至用戶端，或是將伺服器端 XML API 端點遷移至 JSON，並使用 JavaScript 執行用戶端算繪，將 JSON 轉換為 HTML DOM 和 CSS。

JavaScript 中的用戶端 XSLT

市面上提供幾種用戶端 (以 JavaScript 為基礎) XSLT 程式庫，但目前最大的程式庫是由 Saxonica 製作 (請參閱 Saxonica 的完整說明文件)。這項實作作業遠遠超出網頁瀏覽器中的 XSLT 1.0 實作作業，可完整支援最新的 v3.0 標準，最終也會支援正在開發中的 v4.0 標準。

Polyfill

我們提供 polyfill，嘗試讓依賴網頁瀏覽器 XSLT 1.0 實作項目的現有程式碼繼續運作，同時不使用瀏覽器的原生 XSLT 功能。如要瞭解這個 Polyfill，請前往 GitHub。

這個 Polyfill 包含以 WASM 為基礎的 XSLTProcessor 類別功能性 Polyfill 替代項目，因此現有的 JavaScript 程式碼可以繼續照常運作：

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

此外，這個 Polyfill 也提供自動公用程式函式，可輕鬆取代使用 XSLT 處理指令的 XML 文件：

假設原始 demo.xml 檔案如下：

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

只要加入一行，即可叫用 Polyfill，並使用參照的 XSLT 樣式表轉換文件：

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
<script src="xslt-polyfill.min.js"
   xmlns="http://www.w3.org/1999/xhtml"></script>
...content...

在這種情況下，新的 <script> 元素會載入 Polyfill，偵測 XML 文件類型和 XSLT 處理指令，並以透明方式載入，取代文件。

擴充功能

此外，您也可以將 Chrome 擴充功能新增至支援的瀏覽器，這樣系統就會將相同的 XSLT Polyfill 套用至所有含有 XSLT 處理指令或對 XSLTProcessor 的呼叫的原始 XML 網頁。如果無法變更來源 XML 或 XSLT，即可使用這項功能來維持功能。

具體來說，如果停用 XSLT，Chrome 現在會顯示警告橫幅，並直接連結至擴充功能搜尋頁面，協助使用者尋找擴充功能：

Chrome 偵測到 xslt 時顯示的訊息。

特定用途

在 HTML 標準的討論中，我們發現了幾個具體的用途。本節將逐一說明這些項目，並為目前發布使用 XSLT 的 XML 資源的開發人員，建議可行的解決方案。

RSS 和 Atom 動態消息

在許多現有的 RSS 或 Atom 動態消息中，XSLT 用於在直接透過瀏覽器檢視時，將原始 XML 動態消息轉換為人類可讀的格式。主要用途是當使用者不小心點選網站的 RSS 饋給連結時，系統會提供格式化的 HTML 回應供使用者閱讀，而不是原始 XML，因此使用者不必將該連結貼到 RSS 閱讀器。

這個用途有兩種解決方案。如要以「標準」HTML 方式執行這項操作，請在 (以 HTML 為基礎的) 網站中加入 <link rel="alternate" type="application/rss+xml">，而不是加入使用者可能會不小心點選的明確 (使用者可見) <a href="something.xml">。這項解決方案可讓 RSS 閱讀器在使用者只貼上網站網址時找到動態消息，同時也讓使用者看到一般 HTML 內容，不會因 XML 資源的連結而感到困惑。這也遵循一般網路範例，也就是 HTML 適用於人類，XML 適用於機器。當然，如果使用者只是「擁有」某處的 RSS 連結，並將其貼到網路瀏覽器 (而非 RSS 閱讀器) 中，這就無法解決問題。

如果不需要該解決方案，可透過 Polyfill 採用其他路徑。如先前所述，RSS/Atom XML 動態消息可透過一行 <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script> 擴增，這會維持現有的 XSLT 轉換至 HTML 行為。由於 <script> 是根元素的直接子項，因此這項異動不應影響 RSS 閱讀器繼續剖析 XML 的能力。

內嵌式裝置的 API 輸出內容

部分商用嵌入式裝置會測量或產生 XML 資料，供本機網路上的使用者使用。部分裝置會產生單一 XML 資料動態饋給，並使用 XSLT 將其轉換為人類可讀的 HTML 格式。這樣一來，您就能直接在瀏覽器中查看 API，不必在裝置或瀏覽器中加入額外程式碼。
由於這是非常特定於應用程式的用途，解決方案的形狀可能會有所不同。如果應用程式可更新嵌入式裝置的原始碼，則可使用先前所述的任何選項 (JSON、Polyfill)。不過，許多這類裝置基於各種原因，難以或無法更新。在這種情況下，擴充功能可能是最佳選擇，因為這樣一來，用戶端瀏覽器就能繼續以完全相同的方式讀取資料，不必修改裝置。

網站的延遲範本

有時網頁開發人員會在用戶端使用 XSLT，將呈現標記套用至語意標記，做為與 JavaScript 生態系統分開的延遲範本語言。

這個更普遍的問題有兩種解決方案。如果是以這種方式建構的現有網站，最簡單的解決方案可能就是加入 Polyfill，以維持現有功能。或者，您也可以在伺服器端執行 XSLT 轉換，然後將產生的 HTML 提供給用戶端，而不是原始 XML。如要長期解決這類屬性的問題，建議改用更現代的 JavaScript 或 JSON 架構。