Google 会使用 AI 技术将内容翻译成您偏好的语言。AI 翻译可能包含错误。

移除 XSLT 以打造更安全的浏览器

Mason Freed

Dominik Röttsches

发布时间：2025 年 10 月 29 日

Chrome 打算弃用 XSLT，并将其从浏览器中移除。本文档详细介绍了如何在 2026 年底移除之前迁移代码。

Chromium 已正式弃用 XSLT，包括 XSLTProcessor JavaScript API 和 XSLT 处理指令。我们计划从 158 版（2026 年 11 月 17 日）开始移除支持。Firefox 和 WebKit 项目也表示计划从其浏览器引擎中移除 XSLT。本文档提供了一些历史背景信息，说明了我们如何移除 XSLT 以提高 Chrome 的安全性，并提供了在从浏览器中移除这些功能之前进行迁移的途径。如需了解最新动态，另请参阅 Chrome Platform Status 条目。

哪些内容将被移除？

浏览器中有两个 API 实现了 XSLT，这两个 API 都将被移除：

XSLTProcessor 类（例如 new XSLTProcessor()）。
XSLT 处理指令（例如 <?xml-stylesheet type="text/xsl" ... ?>）。

Chrome 的时间轴

Chrome 团队有以下计划：

Chrome 142（2025 年 10 月 28 日）：Chrome 中添加了预警控制台消息。
Chrome 143（2025 年 12 月 2 日）：正式弃用该 API - 控制台和 Lighthouse 中开始显示弃用警告消息。
Chrome 145（2025 年 12 月 2 日 Canary）：Canary、Dev 和 Beta 版本开始默认停用 XSLT，作为早期警告。
Chrome 146（2026 年 3 月 10 日）：企业政策 (EP) 上线，供测试。这让企业既能提前测试停用 XSLT 的效果，也能在功能移除后继续使用相关功能。
Chrome 152（2026 年 8 月 25 日）：源试用 (OT) 上线，供测试使用。这让网站能够在功能移除后继续使用相关功能。
Chrome 154（2026 年 9 月 22 日）：Webview Canary 版、开发者版和 Beta 版开始默认停用 XSLT，作为早期警告。
Chrome 158（2026 年 11 月 17 日）：除“源试用”和“企业政策”参与者外，XSLT 将停止在稳定版中运行。
Chrome 176（2027 年 8 月 17 日）：源试用和企业政策停止运行。系统将为所有用户停用 XSLT。

什么是 XSLT？

XSLT（可扩展样式表语言转换）是一种用于转换 XML 文档（通常转换为 HTML 等其他格式）的语言。它使用 XSLT 样式表文件来定义此转换的规则，并使用包含用作输入的数据的 XML 文件。

在浏览器中，当收到链接到 XSLT 样式表的 XML 文件时，浏览器会使用该样式表中的规则来重新排列、设置格式并将原始 XML 数据转换为可为用户呈现的结构化网页（通常为 HTML）。

例如，XSLT 样式表可以采用以下 XML 输入：

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&quo>t<; hr>ef<=">demo.xsl" ?
<page
 me>s<sage
>  Hello World.
 /message
/page

以及以下 XSL 样式表：

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Trans>for<m"
  xsl:output meth>od=<"html"/
  xsl:template m>atch=<&quo>t;/page</>message&q<uot;
    body
      pMes><sa>ge: x<sl:va>lue<-of select=&q>u<ot;."//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 处理器，使客户端 XML 到 HTML 转换成为 21 世纪初一种可行的 Web 技术。

XSLT 语言本身也在不断发展，2007 年发布了 XSLT 2.0，2017 年发布了 XSLT 3.0，引入了正则表达式、改进的数据类型和处理 JSON 的能力等强大功能。不过，浏览器支持却停滞不前。目前，所有主流网络浏览器引擎都仅原生支持 1999 年发布的原始 XSLT 1.0。由于技术停滞不前，加之 JSON 作为传输格式的使用量不断增加，以及 JavaScript 库和框架（如 jQuery、React 和 Vue.js）提供了更灵活、更强大的 DOM 操作和模板功能，客户端 XSLT 的使用量已大幅下降。在网络浏览器中，它的地位已大不如前，很大程度上被这些基于 JavaScript 的技术所取代。

为什么需要移除 XSLT？

网络浏览器中继续包含 XSLT 1.0 会带来重大且不必要的安全风险。处理这些转换的底层库（例如 Chromium 浏览器使用的 libxslt）是复杂且老旧的 C/C++ 代码库。这类代码极易受到缓冲区溢出等内存安全漏洞的影响，从而可能导致任意代码执行。例如，安全审核和 bug 跟踪器已多次在这些解析器中发现高严重性漏洞（例如，libxslt 中的 CVE-2025-7425 和 CVE-2022-22834）。由于客户端 XSLT 已沦为一项极少使用的边缘化功能，相关库所获得的维护与安全审查远不及核心 JavaScript 引擎；然而，在处理不受信任的 Web 内容时，它们却构成了一个直接且极具威胁的攻击面。事实上，XSLT 正是近期多起备受瞩目的安全攻击的根源，这些攻击持续威胁着浏览器用户的安全。维护这种脆弱的旧版功能所带来的安全风险远远超过其有限的现代实用性。

此外，客户端 XSLT 的原始用途（将数据转换为可渲染的 HTML）已被更安全、更符合人体工程学且维护更好的 JavaScript API 取代。现代 Web 开发依赖于 Fetch API 等工具来检索数据（通常为 JSON），以及 DOMParser API 来在浏览器安全的 JavaScript 沙盒中安全地将 XML 或 HTML 字符串解析为 DOM 结构。React、Vue 和 Svelte 等框架随后会高效、安全地管理这些数据的渲染。这个现代工具链正在积极开发中，受益于 JavaScript 引擎中的大量安全投资，并且几乎所有 Web 开发者都在使用。事实上，目前只有大约 0.02% 的网页加载实际使用了 XSLT，而使用 XSLT 处理指令的比例不到 0.001%。

这并非 Chrome 或 Chromium 独有的举措：另外两大主流浏览器引擎也支持从 Web 平台中移除 XSLT：WebKit、Gecko。

基于上述原因，弃用并移除 XSLT 可以减少浏览器对所有用户的攻击面，简化 Web 平台，并使工程资源能够专注于保护实际为现代 Web 提供支持的技术，而不会对开发者的能力造成实际损失。

提高 XML 解析安全性

与 libxslt 中的严重安全问题类似，最近有人报告了 libxml2 中存在严重的安全问题，Chromium 使用 libxml2 来解析、序列化和测试 XML 的格式是否正确。为了解决 Chromium 中 XML 解析的未来安全问题，我们计划逐步淘汰 libxml2 的使用，并用 Rust 编写的内存安全 XML 解析库替换 XML 解析。重要的是，我们不会从浏览器中移除 XML；此处仅考虑移除 XSLT。我们希望确保替换 libxml2 对 Web 开发者来说是完全透明的。

XML + CSS 不会被移除

请务必区分 XSLT (<?xml-stylesheet type="text/xsl" ... ?>) 的弃用与 <?xml-stylesheet ... ?> 处理指令本身，后者在与 CSS 搭配使用时仍受支持。您仍然可以像使用 HTML 一样，将处理指令与 type="text/css" 搭配使用，以便将标准布局和设计规则应用于原始数据。例如：

<?xml version="1.0" encodin>g<="UTF-8"?
?xml-stylesheet type="tex>t</css>&qu<ot; >href="s<tyles>.<css&q>uot;?
root
  itemContent here/item
/root

如何迁移

有几种不同的迁移路径。

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 的功能性 polyfill 替代项，用于替换 XSLTProcessor 类，因此现有的 JavaScript 代码可以继续按原样运行：

<script src="xslt-polyfill.mi><n.js&qu>ot<;/scri>pt

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

该 polyfill 还提供了一个自动实用函数，可轻松替换使用 XSLT 处理指令的 XML 文档：

对于如下所示的原始 demo.xml 文件：

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>ref="demo.xsl"?
ROOT
...content...

可以添加一行代码来调用 polyfill，并使用引用的 XSLT 样式表转换文档：

<?xml version=">1<.0"?
?xml-stylesheet type="text/xsl&qu>o<t; h>r<ef="demo.xsl"?
ROOT
script src="xslt-polyfill.min.js"><
   xml>ns="http://www.w3.org/1999/xhtml"/script
...content...

在这种情况下，新的 <script> 元素会加载 polyfill，后者会检测 XML 文档类型和 XSLT 处理指令，并以透明方式加载它，从而替换文档。

扩展程序

此外，还有一个 Chrome 扩展程序，可以添加到受支持的浏览器中，该扩展程序会将相同的 XSLT polyfill 应用于所有包含 XSLT 处理指令或 XSLTProcessor 调用的原始 XML 页面。这可用于无法更改源 XML 或 XSLT 的应用，以维持功能。

具体而言，当 XSLT 被停用时，Chrome 现在会显示一个警告横幅，其中包含直接指向扩展程序搜索页面的链接，以帮助用户找到扩展程序：

检测到 xslt 时在 Chrome 中显示的消息。

具体应用场景

在 HTML 标准讨论中，确定了几个具体用例。本部分将专门讨论每种方法，以便为目前发布使用 XSLT 的 XML 资源的开发者推荐后续路径。

RSS 和 Atom Feed

在许多现有的 RSS 或 Atom Feed 中，XSLT 用于使原始 XML Feed 在浏览器中直接查看时可供人类阅读。主要应用场景是，当用户误点击网站的 RSS Feed 链接时，他们会获得可阅读的格式化 HTML 响应，而不是原始 XML 本身，而不是将该链接粘贴到其 RSS 阅读器中。

此应用场景有两种实现路径。“标准”HTML 做法是向（基于 HTML 的）网站添加 <link rel="alternate" type="application/rss+xml">，而不是添加用户可能会发生误点击的显式（用户可见）<a href="something.xml">。这样，如果用户仅粘贴网站网址，RSS 阅读器也能找到 Feed，同时人类用户也能看到常规 HTML 内容，而不会被 XML 资源的链接所困扰。这也遵循了正常的网络范式，即 HTML 供人类使用，XML 供机器使用。当然，这并不能解决用户只是从某个地方“获取”了 RSS 链接，并将其粘贴到网络浏览器（而非 RSS 阅读器）中的情况。

如果不需要该解决方案，polyfill 会提供另一种途径。如前所述，RSS/Atom XML Feed 可以增加一行 <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>，这将保持基于 XSLT 的 HTML 转换的现有行为。这应该不会影响 RSS 阅读器继续解析 XML 的能力，因为 <script> 是根元素的直接子级。

嵌入式设备的 API 输出

某些商用嵌入式设备会测量或以其他方式生成 XML 数据，供本地网络上的用户使用。其中一些设备通过生成单个 XML 数据 Feed 来实现此目的，该 Feed 使用 XSLT 将其转换为人类可读的 HTML 格式。这样，您就可以直接在浏览器中查看 API，而无需在设备或浏览器中添加额外的代码。
由于这是一个非常具体的应用场景，因此解决方案的形式可能会有所不同。对于可以更新嵌入式设备源代码的应用，上述任何选项（JSON、Polyfill）都可能适用。不过，由于各种原因，许多此类设备很难或无法更新。在这种情况下，扩展程序可能是最佳选择，因为它允许客户端浏览器继续以完全相同的方式读取数据，而无需修改设备。

网站的延迟模板化

Web 开发者有时会在客户端使用 XSLT 将展示标记应用于语义标记，作为独立于 JavaScript 生态系统的延迟模板语言。

针对这个更普遍的问题，有两种解决方案。对于以这种方式构建的现有网站，最简单的解决方案可能就是添加 polyfill 以维持现有功能。或者，您也可以在服务器端执行 XSLT 转换，然后将生成的 HTML（而非原始 XML）提供给客户端。对于此类属性，更长期的解决方案是迁移到更现代的 JavaScript 或基于 JSON 的框架。

如果您在 Chrome 中遇到与此 XSLT 弃用相关的特定问题，请在此处报告 bug。

如何检测 XSLT 的使用情况

通常，您可以通过几种方式在代码库中检测 XSLT 等已弃用的功能。本部分概述了其中两种方法。

Reporting API

Reporting API 是一种通用报告机制，可供 Web 应用报告各种平台功能和条件，包括功能弃用。如需将其设置为报告 XSLT 弃用情况，可以使用如下代码段：

new ReportingObserver((reports, observer) => {
  reports.forEach((report) => {
    if (report.body.id === "XSLT") {
      // XSLT usage was detected - report it back here.
    }
  });
}, {types: ["deprecation"],buffered: true}).observe();

在 CodePen 上查看此代码的实际效果。

企业“旧版技术”报告

对于企业管理员，旧版技术报告可用于自动收集已弃用的功能使用情况，并以人性化的方式报告这些信息。如需详细了解如何启用此功能，请参阅这篇 Google 支持文章。