公開日: 2025 年 10 月 29 日
Chrome は、ブラウザから XSLT を非推奨にして削除する予定です。このドキュメントでは、2026 年後半の削除前にコードを移行する方法について詳しく説明します。
Chromium は、XSLTProcessor JavaScript API と XML スタイルシート処理命令を含め、XSLT を正式に非推奨としました。バージョン 155（2026 年 11 月 17 日）からサポートを終了する予定です。Firefox プロジェクトと WebKit プロジェクトも、ブラウザ エンジンから XSLT を削除する計画を示しています。このドキュメントでは、XSLT を削除して Chrome の安全性を高める方法について、その経緯と背景を説明します。また、ブラウザからこれらの機能が削除される前に移行するための手順も説明します。
削除されるものは何ですか？
ブラウザには XSLT を実装する 2 つの API がありますが、どちらも削除されます。
- XSLTProcessor クラス（例:
new XSLTProcessor()）。 - XSLT 処理命令（
<?xml-stylesheet … ?>など）。
Timeline For Chrome
Chrome には次のプランがあります。
- Chrome 142（2025 年 10 月 28 日）: Chrome に早期警告コンソール メッセージを追加。
- Chrome 143（2025 年 12 月 2 日）: API の正式なサポート終了 - サポート終了に関する警告メッセージがコンソールと Lighthouse に表示され始めます。
- Chrome 148（2026 年 3 月 10 日 Canary）: Canary、Dev、Beta リリースで、早期警告として XSLT がデフォルトで無効になります。
- Chrome 152（2026 年 8 月 25 日）: オリジン トライアル（OT）とエンタープライズ ポリシー（EP）がテスト用にリリースされます。これにより、サイトや企業は削除日を過ぎても機能を引き続き使用できます。
- Chrome 155（2026 年 11 月 17 日）: オリジン トライアルとエンタープライズ ポリシーの参加者以外のすべてのユーザーを対象に、安定版リリースで XSLT が機能しなくなります。**
- Chrome 164（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" 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 処理命令に加えて、ローカルの XML ドキュメントをローカルの XSLT スタイルシートで処理するために使用できる XSLTProcessor JavaScript API もあります。
XSLT の歴史
XSLT は、XML ドキュメントを他の形式（ウェブブラウザで表示するための HTML など）に変換する言語として、1999 年 11 月 16 日に World Wide Web 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++ コードベースです。このタイプのコードは、バッファ オーバーフローなどのメモリ安全性の脆弱性の影響を受けやすく、任意のコード実行につながる可能性があります。たとえば、セキュリティ監査やバグトラッカーでは、これらのパーサーで重大度の高い脆弱性が繰り返し特定されています（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 エンジンへの大規模なセキュリティ投資の恩恵を受けています。また、現在、ほぼすべてのウェブ デベロッパーがこのツールチェーンを使用しています。実際、現在 XSLT を使用しているウェブページの読み込みは 0.02% 程度にすぎず、XSLT 処理命令を使用しているのは 0.001% 未満です。
これは Chrome や Chromium 固有の措置ではありません。他の 2 つの主要なブラウザ エンジン（WebKit、Gecko）も、ウェブ プラットフォームからの XSLT の削除をサポートしています。
これらの理由から、XSLT を非推奨にして削除することで、すべてのユーザーのブラウザの攻撃対象領域が縮小され、ウェブ プラットフォームが簡素化され、デベロッパーの機能が実質的に損なわれることなく、エンジニアリング リソースを最新のウェブを実際に支えるテクノロジーの保護に集中させることができます。
XML 解析のセキュリティを改善
libxslt の深刻なセキュリティ上の問題と同様に、Chromium で XML の解析、シリアル化、整形式のテストに使用される libxml2 に対して、深刻なセキュリティ 上の問題が最近報告されました。Chromium での XML 解析に関する将来のセキュリティ問題を解決するため、libxml2 の使用を段階的に廃止し、XML 解析を Rust で記述されたメモリセーフな 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 標準を完全にサポートしています。
ポリフィル
ブラウザの XSLT 1.0 の実装に依存する既存のコードが、ブラウザのネイティブ XSLT 機能を使用せずに引き続き機能するようにするポリフィルがあります。ポリフィルは GitHub にあります。
このポリフィルには、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>
このポリフィルには、XSLT 処理命令を使用する XML ドキュメントを簡単に置き換えるための自動ユーティリティ関数も用意されています。
次のような元の demo.xml ファイルの場合:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
1 行を追加して、ポリフィルを呼び出し、参照される 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 処理命令または XSLTProcessor の呼び出しを含むすべての未加工の XML ページに同じ XSLT ポリフィルを適用します。これは、ソース XML または XSLT を変更できないアプリケーションで、機能を維持するために使用できます。
特に、XSLT が無効になっている場合、Chrome には拡張機能の検索ページに直接リンクする警告バナーが表示され、ユーザーが拡張機能を見つけやすくなります。
具体的なユースケース
HTML 標準に関する議論では、いくつかの具体的なユースケースが特定されました。このセクションでは、現在 XSLT を使用する XML リソースを公開しているデベロッパー向けに、今後の方向性を推奨するため、それぞれの方法について詳しく説明します。
RSS フィードと Atom フィード
既存の RSS フィードや Atom フィードの多くでは、ブラウザで直接表示したときに未加工の XML フィードを人間が読めるようにするために XSLT が使用されています。主なユースケースは、ユーザーがサイトの RSS フィード リンクを誤ってクリックした場合に、そのリンクを RSS リーダーに貼り付けるのではなく、生の XML ではなく、読み取り可能な形式の HTML レスポンスを取得することです。
このユースケースには 2 つのパスがあります。この処理を行う標準的な HTML の方法は、ユーザーが誤ってクリックする可能性のある明示的な（ユーザーに表示される）<a
href="something.xml"> を追加するのではなく、<link rel="alternate" type="application/rss+xml"> を（HTML ベースの）サイトに追加することです。このソリューションでは、ユーザーがウェブサイトの URL のみを貼り付けた場合、RSS リーダーがフィードを見つけることができます。また、人間が XML リソースへのリンクに混乱することなく、通常の HTML コンテンツを表示することもできます。これは、HTML は人間向け、XML は機械向けという通常のウェブ パラダイムにも沿っています。もちろん、ユーザーがどこかから RSS リンクを取得して、RSS リーダーではなくウェブブラウザに貼り付けるケースは解決されません。
このソリューションが不要な場合は、ポリフィルで別の方法を利用できます。前述のように、RSS/Atom XML フィードに 1 行の <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 データを測定または生成します。一部のデバイスでは、XSLT を使用して人が読める HTML 形式に変換する単一の XML データフィードを生成することで、この処理を行っています。これにより、デバイスやブラウザに追加のコードを必要とせずに、ブラウザで API を直接表示できます。
これはアプリケーション固有のユースケースであるため、ソリューションの形状は異なる場合があります。組み込みデバイスのソースコードを更新できるアプリケーションでは、前述のオプション（JSON、Polyfill）のいずれも使用できます。ただし、さまざまな理由により、このようなデバイスの多くは更新が困難または不可能になっています。この場合、デバイスを変更せずにクライアント ブラウザでまったく同じ方法でデータを読み取ることができるため、拡張機能が最適な選択肢となる可能性があります。
ウェブサイトの遅延テンプレート
ウェブ デベロッパーは、クライアントサイドで XSLT を使用して、プレゼンテーション マークアップをセマンティック マークアップに適用することがあります。これは、JavaScript エコシステムとは別の遅延テンプレート言語として機能します。
このより一般的な問題には、2 つの解決策があります。この方法で構築された既存のサイトの場合、既存の機能を維持するためにポリフィルを追加するのが最も簡単な解決策です。または、サーバー側で XSLT 変換を実行し、未加工の XML ではなく、結果の HTML をクライアントに提供することもできます。このようなプロパティのより長期的な解決策は、より最新の JavaScript または JSON ベースのフレームワークに移行することです。