ブラウザの安全性を高めるための XSLT の削除

Mason Freed

Dominik Röttsches

公開日: 2025 年 10 月 29 日

Chrome では、ブラウザから XSLT を非推奨にして削除する予定です。このドキュメントでは、2026 年後半に削除される前にコードを移行する方法について説明します。

Chromium では、XSLTProcessor JavaScript API や XSLT 処理命令を含む XSLT が正式に非推奨となりました。バージョン 158（2026 年 11 月 17 日）でサポートを終了する予定です。Firefox プロジェクトと WebKit プロジェクトでも、ブラウザ エンジンから XSLT を削除する計画が示されています。このドキュメントでは、これまでの経緯と背景、Chrome の安全性を高めるために XSLT を削除する方法、これらの機能がブラウザから削除される前に移行する方法について説明します。最新の更新情報については、Chrome プラットフォーム ステータス エントリもご覧ください。

注: セキュリティをさらに強化するため、Chrome 内の XML 解析を libxml2 から Rust で記述された XML パーサーに移行する予定です。

削除されるもの

ブラウザには XSLT を実装する API が 2 つあり、どちらも削除されます。

• 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、Dev、Beta リリースで、早期警告として XSLT がデフォルトで無効になります。
• Chrome 158（2026 年 11 月 17 日）: オリジン トライアルとエンタープライズ ポリシーの参加者以外のすべてのユーザーを対象に、安定版リリースで XSLT が機能しなくなります。
• Chrome 176（2027 年 8 月 17 日）: オリジン トライアルとエンタープライズ ポリシーが機能しなくなります。すべてのユーザーに対して XSLT が無効になります。

XSLT とは

XSLT（Extensible Stylesheet Language Transformations）は、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 に処理します。

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

前の例で示した XSL 処理命令に加えて、XSLTProcessor JavaScript API もあります。これを使用すると、ローカル XSLT スタイルシートでローカル XML ドキュメントを処理できます。

XSLT の歴史

XSLT は、XML ドキュメントを他の形式（最も一般的なのはウェブブラウザに表示するための HTML）に変換するための言語として、1999 年 11 月 16 日に ワールド ワイド ウェブ Consortium（W3C）によって推奨されました。公式の 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 の利用や、より柔軟かつ強力な DOM 操作とテンプレート化を実現する JavaScript ライブラリやフレームワーク（jQuery、React、Vue.js など）の普及により、クライアントサイド XSLT の利用は著しく減少しました。ウェブブラウザ内での役割は、これらの JavaScript ベースのテクノロジーに大きく取って代わられています。

XSLT を削除する必要があるのはなぜですか？

ウェブブラウザに XSLT 1.0 が引き続き含まれていることは、重大かつ不要なセキュリティ リスクをもたらします。これらの変換を処理する基盤となるライブラリ（Chromium ブラウザで使用される libxslt など）は、複雑で古い C/C++ コードベースです。この種のコードは、バッファ オーバーフローなどのメモリ安全性の脆弱性を抱えやすいことで悪名高く、任意のコード実行を招くリスクを伴います。たとえば、セキュリティ監査やバグトラッカーでは、これらのパーサーで重大度の高い脆弱性が繰り返し特定されています（例: libxslt の CVE-2025-7425 と CVE-2022-22834）。クライアントサイド 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 だけの対応ではありません。他の 2 つの主要なブラウザ エンジン（WebKit、Gecko）も、ウェブ プラットフォームからの XSLT の削除をサポートしています。

このような理由から、XSLT を非推奨にして削除することで、すべてのユーザーに対してブラウザの攻撃対象領域を減らし、ウェブ プラットフォームを簡素化できます。また、デベロッパーの機能が実質的に失われることなく、エンジニアリング リソースを最新のウェブを実際に支えるテクノロジーの保護に集中させることができます。

XML 解析のセキュリティを強化

libxslt の重大なセキュリティ問題と同様に、Chromium で XML の解析、シリアル化、整形式のテストに使用される libxml2 に対して、重大なセキュリティ問題が最近報告されました。Chromium での XML 解析に関する将来のセキュリティ問題に対処するため、libxml2 の使用を段階的に廃止し、XML 解析を Rust で記述されたメモリセーフな XML 解析ライブラリに置き換える予定です。重要な点として、ブラウザから XML が削除されることはありません。ここで削除が検討されているのは XSLT のみです。libxml2 の置き換えがウェブ デベロッパーにとって完全に透過的になるようにする予定です。

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 標準をサポートします。

ポリフィル

ウェブブラウザの XSLT 1.0 の実装に依存する既存のコードを、ブラウザのネイティブ XSLT 機能を使用せずに引き続き機能させようとするポリフィルがあります。ポリフィルは GitHub にあります。

このポリフィルには、XSLTProcessor クラスの機能的な WASM ベースのポリフィル置換が含まれているため、既存の 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

このポリフィルには、XSLT 処理命令を使用する XML ドキュメントを簡単に置き換えるための自動ユーティリティ関数も用意されています。

次のような元の demo.xml ファイルの場合:

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

ポリフィルを呼び出し、参照された XSLT スタイルシートでドキュメントを変換するために、1 行追加できます。

<?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> 要素はポリフィルを読み込みます。ポリフィルは XML ドキュメント タイプと XSLT 処理命令を検出し、透過的に読み込んでドキュメントを置き換えます。

広告表示オプション

サポートされているブラウザに追加できる Chrome 拡張機能もあります。この拡張機能は、XSLT 処理命令または XSLTProcessor の呼び出しを含むすべての未加工の XML ページに同じ XSLT ポリフィルを適用します。これは、ソース XML または XSLT を変更できないアプリケーションで、機能を維持するために使用できます。

特に、XSLT が無効になっている場合、Chrome には拡張機能の検索ページに直接リンクする警告バナーが表示され、ユーザーが拡張機能を見つけやすくなります。

具体的なユースケース

HTML 標準に関するディスカッションでは、いくつかの具体的なユースケースが特定されました。このセクションでは、現在 XSLT を使用する XML リソースを公開しているデベロッパーに推奨される今後のパスについて、それぞれ具体的に説明します。

RSS フィードと Atom フィード

既存の RSS フィードや Atom フィードの多くでは、XSLT を使用して、ブラウザで直接表示したときに未加工の XML フィードが人が読める形式になるようにしています。主なユースケースは、ユーザーがサイトの RSS フィードリンクを誤クリックした場合に、そのリンクを RSS リーダーに貼り付けるのではなく、未加工の XML 自体ではなく、読み取り可能な形式の HTML レスポンスを取得することです。

このユースケースには 2 つの方法があります。これを HTML で行う「標準」の方法は、ユーザーが誤クリックする可能性のある明示的な（ユーザーに表示される）<a href="something.xml"> を追加するのではなく、（HTML ベースの）サイトに <link rel="alternate" type="application/rss+xml"> を追加することです。このソリューションを使用すると、ユーザーがウェブサイトの URL を貼り付けるだけで、RSS リーダーがフィードを検出できるようになります。また、人間のユーザーは、XML リソースへのリンクに混乱することなく、通常の HTML コンテンツを表示できます。これは、HTML は人間向け、XML はマシン向けという通常のウェブ パラダイムにも沿っています。もちろん、ユーザーがどこかから RSS リンクを「取得」し、それを（RSS リーダーではなく）ウェブブラウザに貼り付ける場合は、この方法では解決できません。

この解決策が望ましくない場合は、polyfill が別のパスを提供します。前述のように、RSS / Atom XML フィードに 1 行（<script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>）を追加することで、XSLT ベースの HTML 変換の既存の動作を維持できます。<script> はルート要素の直接の子であるため、RSS リーダーが XML の解析を続行する機能には影響しません。

組み込みデバイスの API 出力

一部の商用組み込みデバイスは、ローカル ネットワーク上のユーザーが使用する XML データを測定または生成します。これらのデバイスの一部は、XSLT を使用して人が読める HTML 形式に変換する単一の XML データフィードを生成することで、この処理を行います。これにより、デバイスやブラウザに追加のコードを必要とせずに、ブラウザで API を直接表示できます。
これは非常にアプリケーション固有のユースケースであるため、ソリューションの形状は異なる場合があります。組み込みデバイスのソースコードを更新できるアプリケーションの場合は、前述のオプション（JSON、Polyfill）のいずれかを使用できます。特に、そのようなデバイスの多くは、さまざまな理由から更新が困難または不可能です。その場合は、拡張機能が最適なオプションです。これにより、クライアント ブラウザはデバイスを変更することなく、まったく同じ方法でデータを読み取り続けることができます。

ウェブサイトの遅延テンプレート

ウェブ デベロッパーは、クライアントサイドで XSLT を使用して、セマンティック マークアップにプレゼンテーション マークアップを適用することがあります。これは、JavaScript エコシステムとは別の遅延テンプレート言語として機能します。

このより一般的な問題には、2 つの解決策があります。この方法で構築された既存のサイトの場合、最も簡単な解決策は、ポリフィルを追加して既存の機能を維持することです。または、サーバー側で XSLT 変換を実行し、未加工の XML ではなく、結果の HTML をクライアントに提供します。このようなプロパティのより長期的なソリューションは、より最新の JavaScript または JSON ベースのフレームワークに移行することです。

この XSLT のサポート終了に関連して Chrome で特定の問題が発生した場合は、こちらからバグを報告してください。

XSLT の使用を検出する方法

一般に、XSLT などの非推奨の機能は、いくつかの方法でコードベースで検出できます。このセクションでは、そのうちの 2 つについて説明します。

Reporting API

Reporting API は、ウェブ アプリケーションがさまざまなプラットフォーム機能や条件（機能のサポート終了など）に関するレポートを使用するための一般的なレポート メカニズムです。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 サポートの記事をご覧ください。