このページは Cloud Translation API によって翻訳されました。

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

Mason Freed

Dominik Röttsches

公開日: 2025 年 10 月 29 日

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

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

削除されるものは何ですか？

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

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 を含め続けることは、重大かつ不必要なセキュリティリスクをもたらします。これらの変換を処理する基盤となるライブラリ（libxslt（Chromium ブラウザで使用）など）は、複雑で老朽化した 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 の深刻なセキュリティ問題と同様に、XML の整形式の解析、シリアル化、テストに Chromium で使用されている 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...

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

<?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 には拡張機能の検索ページに直接リンクする警告バナーが表示され、ユーザーが拡張機能を見つけやすくなります。

xslt が検出されたときに Chrome に表示されるメッセージ。

具体的なユースケース

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

RSS フィードと Atom フィード

既存の RSS フィードや Atom フィードの多くでは、ブラウザで直接表示したときに未加工の XML フィードを人間が読めるようにするために XSLT が使用されています。主なユースケースは、ユーザーがサイトの 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 リーダーではなくウェブブラウザに貼り付けた場合は、この方法では解決できません。

この解決策が望ましくない場合、ポリフィルは別の方法を提供します。前述のように、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 サポート記事をご覧ください。