此页面由 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 将停止在稳定版中运行，但 Origin 试用和企业政策参与者除外。**
Chrome 164（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" 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 的历史

XSLT 于 1999 年 11 月 16 日被万维网联盟 (W3C) 推荐为一种将 XML 文档转换为其他格式（最常见的是 HTML，以便在 Web 浏览器中显示）的语言。在正式发布 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 的转换在 2000 年代初成为可行的 Web 技术。

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

为什么需要移除 XSLT？

继续在网络浏览器中包含 XSLT 1.0 会带来重大且不必要的安全风险。处理这些转换的底层库（例如 libxslt [由 Chromium 浏览器使用]）是复杂的旧版 C/C++ 代码库。此类代码极易受到内存安全漏洞（如缓冲区溢出）的攻击，从而导致任意代码执行。例如，安全审核和 bug 跟踪器已反复发现这些解析器中存在严重程度较高的漏洞（例如，CVE-2025-7425 和 CVE-2022-22834（均在 libxslt 中）。由于客户端 XSLT 现在是一项很少使用的利基功能，这些库获得的维护和安全审查远少于核心 JavaScript 引擎，但它们代表了处理不受信任的网络内容的直接、强大的攻击面。事实上，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 中存在的严重安全问题，而 libxml2 在 Chromium 中用于解析、序列化和测试 XML 的格式是否正确。为了解决 Chromium 中 XML 解析的未来安全问题，我们计划逐步淘汰 libxml2 的使用，并用 Rust 编写的内存安全 XML 解析库替换 XML 解析。重要的是，我们不会从浏览器中移除 XML；我们目前只考虑移除 XSLT。我们打算确保替换 libxml2 对 Web 开发者完全透明。

如何迁移

迁移有多种替代方案。

JSON

对于完全基于 XML 和 XSL 构建的网站，没有一种通用的迁移方法。迁移选项包括将 XSLT 处理流水线移至服务器端，并将渲染的 HTML 发送到客户端；或者将服务器端 XML API 端点迁移到 JSON，并使用 JavaScript 执行客户端渲染，以将 JSON 转换为 HTML DOM 和 CSS。

JavaScript 中的客户端 XSLT

目前有几个基于 JavaScript 的客户端 XSLT 库，但其中最大的一个是由 Saxonica 制作的（请参阅 Saxonica 的全面文档）。该实现远远超出了 Web 浏览器中的 XSLT 1.0 实现，可完全支持最新的 v3.0 标准，并最终支持正在开发的 v4.0 标准。

Polyfill

有一个 polyfill 试图让依赖于 Web 浏览器 XSLT 1.0 实现的现有代码继续正常运行，同时不使用浏览器中的原生 XSLT 功能。该填充区位于 GitHub 上。

该填充区包含基于 WASM 的 XSLTProcessor 类功能性填充替换项，因此现有 JavaScript 代码可以继续按原样运行：

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

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

该填充区还提供了一个自动实用函数，可用于轻松替换使用 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> 元素会加载填充，该填充会检测 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 资源的链接而感到困惑。这也遵循了正常的 Web 范式，即 HTML 供人类使用，而 XML 供机器使用。当然，这并不能解决用户只是从某处“获得”RSS 链接，然后将其粘贴到网络浏览器（而不是 RSS 阅读器）中的情况。

如果不需要该解决方案，polyfill 会提供另一条途径。如前所述，RSS/Atom XML Feed 可以通过添加一行代码 <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](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 的框架。