ブラウザに長く備わっていたXSLTの機能が、いよいよ外される段階に入った。Chromeの開発者向け資料によると、対象はXSLTProcessorというJavaScriptのクラスと、XMLの先頭に書く text/xsl の処理命令の両方だという。安定版で動かなくなるのはバージョン158、2026年11月17日の予定とされている。8月25日に出たバージョン152からは、期限を過ぎても使い続けたいサイト向けの試験的な仕組みも始まっていて、企業向けのポリシー設定と合わせると2027年8月までは猶予が取れる形になっている。

背景に挙げられているのは安全性の話だ。変換を担ってきたlibxsltは年季の入ったC/C++のコードで、メモリまわりの脆弱性が出やすい。それでいて実際の利用は少なく、XSLTが関わるページ表示は全体の0.02%ほど、処理命令に限れば0.001%未満だという。使われる機会に対して攻撃対象としての面積が大きすぎる、という判断になる。同じ理由でXMLの解析に使われてきたlibxml2にも深刻な問題が報告されており、土台ごと見直す流れになっている。WebKitとGeckoも同じ方向を示しているので、Chromeだけの事情ではない。

影響が見えやすいのはサイトマップ

実務で気づきやすいのは、XMLをブラウザで直接開いたときの見え方だろう。WordPressは5.5から標準のXMLサイトマップを持っていて、その出力にXSLのスタイルシートを添えている。おかげでwp-sitemap.xmlを開くとURLの一覧が表形式で表示されるが、XSLTが止まればここは飾りのない生のXMLに戻る。この見た目を作っているXSLはWordPressが動的に出力しているもので、フィルターで内容を差し替えられるようにもなっている。検索エンジンのクローラーはもともとこの処理命令を無視して素のXMLを読んでいるため、インデックスや評価に影響する話ではない。人が目視で中身を確かめるときの見た目だけが変わる。RSSやAtomのフィードを読みやすく整形している場合も事情は同じだ。

移行の道筋もいくつか示されている。変換をサーバー側で済ませてHTMLを返す、データをJSONに寄せて表示はJavaScriptで組み立てる、WebAssemblyで作られたポリフィルを1行足して今の挙動を保つ、といった選択肢だ。フィードについては、XMLへの直リンクを置く代わりにHTML側へ link rel=”alternate” を置くやり方が案内されている。なお、XMLそのものが消えるわけではない。type=”text/css” を指定してCSSで見た目を整える書き方は残るし、ChromeはXMLの解析部分をRustで書かれた実装に差し替える作業も進めている。こちらは開発者から見て違いが出ないようにするという。

自分のサイトで使っているかどうかは、開発者ツールのコンソールに出る非推奨の警告や、Reporting APIを使った検出で確かめられる。企業向けのポリシーやブラウザ拡張で表示を保つ手も残されている。急いで作り直すような話ではないけれど、納品済みのサイトでXMLを直接見せている箇所があるかどうかは、秋が来る前に一度洗い出しておくと落ち着いて手を打てる。