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

Mason Freed
Mason Freed
X GitHub
Dominik Röttsches
Dominik Röttsches
GitHub Mastodon

Published: October 29, 2025

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

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

要移除的内容

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

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 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" 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，该 API 可用于使用本地 XSLT 样式表处理本地 XML 文档。

XSLT 的历史记录

1999 年 11 月 16 日，万维网联盟 (W3C) 推荐使用 XSLT 作为将 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？

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

此外，客户端 XSLT 的最初用途（将数据转换为可呈现的 HTML）已被更安全、更符合人体工程学且维护更好的 JavaScript API 所取代。现代 Web 开发依赖于 Fetch API 来检索数据（通常为 JSON），以及 DOMParser API 来安全地将 XML 或 HTML 字符串解析为浏览器安全 JavaScript 沙盒中的 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 开发者完全透明。

XML + CSS 不会被移除

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

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content here</item>
</root>

如何迁移

有几种替代迁移路径。

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 尝试允许依赖于 Web 浏览器实现的 XSLT 1.0 的现有代码继续运行，同时不使用浏览器中的原生 XSLT 功能。该 polyfill 位于 GitHub 上。

该 polyfill 包含 XSLTProcessor 类的功能性 WASM 填充替换，因此现有 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，该 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 方式是将<link rel="alternate" type="application/rss+xml">添加到 （基于 HTML 的）网站，而不是添加用户可能会意外点击的显式（用户可见）<a href="something.xml">。此解决方案允许 RSS 阅读器在用户仅粘贴网站网址时查找 Feed，但它也允许用户查看常规 HTML 内容，而不会因 XML 资源的链接而感到困惑。这也遵循了 HTML 适用于人类，XML 适用于机器的正常 Web 范例。当然，这并不能解决用户只是从某个地方“拥有”RSS 链接，并将其粘贴到 Web 浏览器（而不是 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 数据，供本地网络上的用户使用。其中一些设备通过生成使用 XSLT 将其转换为人类可读 HTML 格式的单个 XML 数据 Feed 来实现此目的。这样，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 支持 文章。