برداشتن XSLT برای داشتن مرورگری امن‌تر

Mason Freed

Dominik Röttsches

تاریخ انتشار: ۲۹ اکتبر ۲۰۲۵

‫Chrome قصد دارد XSLT را از مرورگر منسوخ و حذف کند. این سند جزئیات نحوه انتقال کدتان را قبل‌از حذف در اواخر سال ۲۰۲۶ شرح می‌دهد.

Chromium رسماً XSLT را منسوخ کرده است، ازجمله XSLTProcessor JavaScript API و دستورالعمل پردازش XSLT. قصد داریم پشتیبانی را از نسخه ۱۵۸ (۱۷ نوامبر ۲۰۲۶) برداریم. پروژه‌های Firefox و WebKit نیز برنامه‌هایی را برای حذف XSLT از موتورهای مرورگر خود نشان داده‌اند. این سند مقداری سابقه و زمینه ارائه می‌دهد، توضیح می‌دهد که چگونه XSLT را برمی‌داریم تا Chrome را ایمن‌تر کنیم، و مسیری برای انتقال قبل‌از برداشته شدن این ویژگی‌ها از مرورگر ارائه می‌دهد. برای جدیدترین به‌روزرسانی‌ها، ورودی وضعیت پلاتفرم Chrome را نیز ببینید.

توجه: برای بهبود بیشتر امنیت، قصد داریم تجزیه XML را در Chrome از libxml2 به تجزیه‌کننده XML نوشته‌شده در Rust منتقل کنیم.

چه چیزی برداشته می‌شود؟

دو API در مرورگر وجود دارد که XSLT را پیاده‌سازی می‌کنند و هر دو درحال برداشته شدن هستند:

• کلاس XSLTProcessor (برای مثال، new XSLTProcessor()).
• دستورالعمل پردازش XSLT (برای مثال، <?xml-stylesheet type="text/xsl" ... ?>).

خط زمان برای Chrome

Chrome طرح زیر را دارد:

• ‫Chrome 142 (‏۲۸ اکتبر ۲۰۲۵): پیام‌های هشدار اولیه کنسول به Chrome اضافه شد.
• ‫Chrome 143 (‏۲ دسامبر ۲۰۲۵): منسوخ شدن رسمی API - پیام‌های هشدار منسوخ شدن در کنسول و lighthouse نشان داده می‌شود.
• ‫Chrome 145 (‏۲ دسامبر ۲۰۲۵ Canary): نسخه‌های Canary،‏ Dev، و Beta به‌عنوان هشدار اولیه، غیرفعال کردن XSLT را به‌طور پیش‌فرض شروع می‌کنند.
• ‫Chrome نسخه ۱۴۶ (۱۰ مارس ۲۰۲۶): خط‌مشی سازمانی (EP) برای آزمایش فعال می‌شود. این کار به شرکت‌ها اجازه می‌دهد هم غیرفعال کردن XSLT را زودتر آزمایش کنند و هم بتوانند پس‌از تاریخ حذف، همچنان از این ویژگی‌ها استفاده کنند.
• ‫Chrome 152 (‏۲۵ اوت ۲۰۲۶): آزمایش معرفی ویژگی جدید (OT) برای آزمایش فعال می‌شود. این کار به سایت‌ها اجازه می‌دهد پس‌از تاریخ حذف، همچنان از ویژگی‌ها استفاده کنند.
• ‫Chrome 154 (‏۲۲ سپتامبر ۲۰۲۶): نسخه‌های Canary،‏ Dev، و Beta از Webview به‌عنوان هشدار اولیه، غیرفعال کردن XSLT را به‌طور پیش‌فرض شروع می‌کنند.
• ‫Chrome 158 (‏۱۷ نوامبر ۲۰۲۶): XSLT در نسخه‌های «پایدار» برای همه کاربران به‌جز شرکت‌کنندگان در «آزمایش معرفی ویژگی جدید» و «خط‌مشی سازمانی» از کار می‌افتد.
• Chrome 176 (‏۱۷ اوت ۲۰۲۷): «آزمایش معرفی ویژگی جدید» و «خط‌مشی سازمانی» از کار می‌افتند. XSLT برای همه کاربران غیرفعال است.

XSLT چیست؟

XSLT، یا Extensible Stylesheet Language Transformations، زبانی است که برای تبدیل اسناد XML، معمولاً به قالب‌های دیگر مانند HTML، استفاده می‌شود. این ابزار از یک فایل برگه سبک نگارش XSLT برای تعریف قوانین این تبدیل و یک فایل XML حاوی داده‌های استفاده‌شده به‌عنوان ورودی استفاده می‌کند.

در مرورگرها، وقتی فایل XML دریافت می‌شود که به برگه سبک نگارش XSLT پیوند دارد، مرورگر از قوانین موجود در آن برگه سبک نگارش برای بازآرایی، قالب‌بندی، و تبدیل داده‌های 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 پردازش می‌کند تا مرورگر نمایش دهد: HTML

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

علاوه‌بر دستورالعمل پردازش XSL که در مثال قبلی نشان داده شد، XSLTProcessor JavaScript API نیز وجود دارد که می‌توان از آن برای پردازش اسناد XML محلی با برگه‌های سبک نگارش XSLT محلی استفاده کرد.

تاریخچه XSLT

XSLT در ۱۶ نوامبر ۱۹۹۹ توسط «کنسرسیوم وب جهان‌گستر» (W3C) به‌عنوان زبانی برای تبدیل اسناد XML به قالب‌های دیگر، معمولاً HTML برای نمایش در مرورگرهای وب، توصیه شد. پیش‌از توصیه رسمی نسخه ۱.۰، Microsoft با ارائه پیاده‌سازی اختصاصی براساس پیش‌نویس کاری W3C در Internet Explorer 5.0 که در مارس ۱۹۹۹ منتشر شد، ابتکار عمل اولیه را به‌دست گرفت. به‌دنبال استاندارد رسمی، Mozilla پشتیبانی XSLT 1.0 بومی را در اواخر سال ۲۰۰۰ در Netscape 6 پیاده‌سازی کرد. مرورگرهای اصلی دیگر، ازجمله Safari،‏ Opera، و بعداً Chrome، نیز پردازنده‌های بومی XSLT 1.0 را در خود جای دادند و تبدیل XML به HTML در سمت کارخواه را به یک فناوری وب قابل‌اجرا در اوایل دهه ۲۰۰۰ تبدیل کردند.

خود زبان XSLT با انتشار XSLT 2.0 در سال ۲۰۰۷ و XSLT 3.0 در سال ۲۰۱۷ به تکامل خود ادامه داد و ویژگی‌های قدرتمندی مانند عبارت‌های باقاعده، انواع داده‌های بهبودیافته، و توانایی پردازش JSON را معرفی کرد. اما پشتیبانی مرورگر راکد ماند. امروزه، همه موتورهای مرورگر وب اصلی فقط از XSLT 1.0 اصلی از سال ۱۹۹۹ پشتیبانی بومی ارائه می‌دهند. این عدم پیشرفت، همراه با افزایش استفاده از JSON به‌عنوان قالب سیم، و کتابخانه‌ها و چارچوب‌های JavaScript (مانند jQuery،‏ React، و Vue.js) که دستکاری و قالب‌بندی DOM انعطاف‌پذیرتر و قدرتمندتری ارائه می‌دهند، منجر به کاهش قابل‌توجهی در استفاده از XSLT سمت کارخواه شده است. نقش آن در مرورگر وب تا حد زیادی با این فناوری‌های مبتنی بر جاوا اسکریپت جایگزین شده است.

چرا XSLT باید برداشته شود؟

گنجاندن مداوم XSLT 1.0 در مرورگرهای وب خطر امنیتی قابل‌توجه و غیرضروری‌ای را ایجاد می‌کند. کتابخانه‌های اساسی که این تبدیل‌ها را پردازش می‌کنند، مانند libxslt (که توسط مرورگرهای Chromium استفاده می‌شود)، پایگاه‌های کد پیچیده و قدیمی C/C++ هستند. این نوع کد به‌طور بدنامی دربرابر آسیب‌پذیری‌های ایمنی حافظه مانند سرریز میان‌گیر حساس است که می‌تواند منجر به اجرای کد اختیاری شود. برای مثال، ممیزی‌های امنیتی و ردیاب‌های اشکال بارها آسیب‌پذیری‌های با شدت بالا را در این تجزیه‌کننده‌ها شناسایی کرده‌اند (مثلاً CVE-2025-7425 و CVE-2022-22834، هر دو در libxslt). ازآنجایی‌که XSLT سمت کارخواه اکنون یک ویژگی خاص و به‌ندرت استفاده‌شده است، این کتابخانه‌ها نسبت‌به موتورهای اصلی JavaScript بسیار کمتر تحت بررسی‌های امنیتی و نگهداری قرار می‌گیرند، بااین‌حال، آن‌ها یک سطح حمله مستقیم و قدرتمند برای پردازش محتوای وب غیرقابل‌اعتماد را نشان می‌دهند. درواقع، XSLT منبع چندین سوءاستفاده امنیتی مهم اخیر است که همچنان کاربران مرورگر را درمعرض خطر قرار می‌دهد. مخاطرات امنیتی حفظ این عملکرد قدیمی و شکننده بسیار بیشتر از کاربرد مدرن و محدود آن است.

علاوه‌براین، هدف اصلی XSLT سمت کارخواه (تبدیل داده‌ها به HTML قابل‌ارائه) با میاناهای برنامه‌سازی کاربردی جاوا اسکریپت که ایمن‌تر، ارگونومیک‌تر، و بهتر نگهداری می‌شوند جایگزین شده است. توسعه وب مدرن به چیزهایی مانند Fetch API برای بازیابی داده‌ها (معمولاً JSON) و DOMParser API برای تجزیه ایمن رشته‌های XML یا HTML به ساختار DOM در محیط امن جاوا اسکریپت مرورگر متکی است. سپس چارچوب‌هایی مانند React،‏ Vue، و Svelte پردازش این داده‌ها را به‌طور مؤثر و ایمن مدیریت می‌کنند. این زنجیره ابزار مدرن به‌طور فعال توسعه یافته است، از سرمایه‌گذاری امنیتی عظیم در موتورهای جاوا اسکریپت بهره می‌برد، و چیزی است که تقریباً همه توسعه‌دهندگان وب امروزه از آن استفاده می‌کنند. درواقع، امروزه فقط حدود ٪۰٫۰۲ از بارگیری‌های صفحه وب از XSLT استفاده می‌کنند و کمتر از ٪۰٫۰۰۱ از دستورالعمل‌های پردازش XSLT استفاده می‌کنند.

این اقدام فقط مختص Chrome یا Chromium نیست: دو موتور مرورگر اصلی دیگر نیز از حذف XSLT از پلاتفرم وب پشتیبانی می‌کنند: WebKit، Gecko.

به این دلایل، منسوخ کردن و برداشتن XSLT سطح حمله مرورگر را برای همه کاربران کاهش می‌دهد، پلاتفرم وب را ساده می‌کند، و به منابع مهندسی اجازه می‌دهد بر ایمن‌سازی فناوری‌هایی تمرکز کنند که درواقع وب مدرن را تقویت می‌کنند، بدون اینکه قابلیت‌های توسعه‌دهندگان عملاً ازبین برود.

بهبود امنیت تجزیه XML

مشابه مشکلات امنیتی شدید در libxslt، اخیراً مشکلات امنیتی شدیدی در libxml2 گزارش شده است که در Chromium برای تجزیه، سریال‌سازی، و آزمایش خوش‌ساخت بودن XML استفاده می‌شود. برای رسیدگی به مشکلات امنیتی آینده در تجزیه XML در Chromium، قصد داریم استفاده از libxml2 را به‌تدریج متوقف کنیم و تجزیه XML را با کتابخانه تجزیه XML ایمن ازنظر حافظه که به زبان Rust نوشته شده است جایگزین کنیم. نکته مهم این است که XML را از مرورگر حذف نخواهیم کرد؛ فقط XSLT برای حذف در اینجا درنظر گرفته شده است. قصد داریم مطمئن شویم که جایگزینی libxml2 کاملاً برای توسعه‌دهندگان وب شفاف است.

XML + CSS برداشته نمی‌شود

مهم است که منسوخ شدن XSLT (<?xml-stylesheet type="text/xsl" ... ?>) را از خود دستورالعمل پردازش <?xml-stylesheet ... ?> که همچنان هنگام استفاده با CSS پشتیبانی می‌شود، متمایز کنیم. همچنان می‌توانید از دستورالعمل پردازش با type="text/css" برای اعمال طرح‌بندی استاندارد و قوانین طراحی به داده‌های خام خود استفاده کنید، درست همان‌طور که می‌توانید با HTML انجام دهید. برای مثال:

<?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 است.

XSLT سمت کارخواه در جاوا اسکریپت

چند کتابخانه XSLT سمت کارخواه (مبتنی بر جاوا اسکریپت) دردسترس است، اما بزرگ‌ترین آن‌ها توسط Saxonica تولید شده است ( مستندات جامع Saxonica را مشاهده کنید). این پیاده‌سازی بسیار فراتر از پیاده‌سازی XSLT 1.0 در مرورگرهای وب است، پشتیبانی کامل از جدیدترین استاندارد نسخه ۳.۰، و درنهایت استاندارد نسخه ۴.۰ درحال توسعه را پیاده‌سازی می‌کند.

شبیه‌ساز مرورگر

یک شبیه‌ساز مرورگر وجود دارد که تلاش می‌کند به کد موجود، که به پیاده‌سازی‌های XSLT 1.0 در مرورگرهای وب وابسته است، اجازه دهد به عملکرد خود ادامه دهد، درحالی‌که از ویژگی‌های بومی XSLT از مرورگر استفاده نمی‌کند. شبیه‌ساز مرورگر در GitHub قرار دارد.

شبیه‌ساز مرورگر حاوی جایگزین شبیه‌سازی‌شده مبتنی بر WASM کاربردی برای کلاس XSLTProcessor است، بنابراین کد جاوا اسکریپت موجود می‌تواند همان‌طور که هست به کار خود ادامه دهد:

<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

شبیه‌ساز مرورگر همچنین یک تابع سودمندی خودکار برای روشی آسان جهت جایگزین کردن اسناد XML که از دستورالعمل‌های پردازش XSLT استفاده می‌کنند ارائه می‌دهد:

برای فایل اصلی demo.xml مانند این:

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

یک خط را می‌توان برای فراخوانی شبیه‌ساز مرورگر و تبدیل سند با برگه سبک نگارش XSLT ارجاع‌شده اضافه کرد:

<?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 را برای همه صفحه‌های XML خام که حاوی دستورالعمل‌های پردازش XSLT یا فراخوانی‌های XSLTProcessor هستند اعمال می‌کند. این ویژگی می‌تواند برای برنامه‌هایی استفاده شود که XML یا XSLT منبع آن‌ها قابل‌تغییر نیست، تا عملکرد آن‌ها حفظ شود.

به‌ویژه، وقتی XSLT غیرفعال است، Chrome اکنون برنمای هشداری نشان می‌دهد که مستقیماً به صفحه جستجوی افزونه پیوند می‌دهد تا به کاربران کمک کند افزونه‌ای را پیدا کنند:

موارد استفاده خاص

در بحث در استانداردهای HTML، چندین مورد استفاده واقعی شناسایی شد. این بخش به‌طور خاص درباره هریک از آن‌ها صحبت می‌کند تا مسیرهای پیش‌رو را برای توسعه‌دهندگانی که منابع XML را بااستفاده از XSLT منتشر می‌کنند توصیه کند.

جارزن‌های هم‌بس و اتم

در بسیاری از فیدهای RSS یا Atom موجود، از XSLT برای تبدیل فیدهای XML خام به فیدهای قابل‌خواندن برای انسان هنگام مشاهده مستقیم در مرورگر استفاده می‌شود. مورد استفاده اصلی این است که وقتی کاربری به‌طور تصادفی روی پیوند فید RSS سایتی کلیک می‌کند، به‌جای جای‌گذاری آن پیوند در RSS خوان خود، پاسخ HTML قالب‌بندی‌شده‌ای دریافت می‌کند که می‌تواند آن را بخواند، به‌جای XML خام.

دو مسیر برای این مورد استفاده وجود دارد. روش HTML «استاندارد» برای انجام این کار، افزودن <link rel="alternate" type="application/rss+xml"> به سایت (مبتنی بر HTML) است، به‌جای افزودن <a href="something.xml"> صریح (قابل‌مشاهده برای کاربر) که ممکن است کاربران به‌طور تصادفی روی آن کلیک کنند. این راهکار به RSSخوان‌ها اجازه می‌دهد تا اگر کاربر فقط نشانی وب سایت را جای‌گذاری کرد، جارزن را پیدا کنند، اما به کاربران انسانی نیز اجازه می‌دهد تا محتوای HTML معمولی را بدون گیج شدن با پیوند به منبع XML ببینند. این امر همچنین از الگوی وب معمولی پیروی می‌کند که HTML برای انسان‌ها و XML برای ماشین‌ها است. البته این مشکل را در مواردی که کاربر فقط یک پیوند RSS از جایی «دارد» و آن را در مرورگر وب خود (به‌جای RSS خوان) جای‌گذاری می‌کند، حل نمی‌کند.

وقتی آن راه‌حل مطلوب نباشد، شبیه‌ساز مرورگر مسیر دیگری را ارائه می‌دهد. همان‌طور که قبلاً ذکر شد، فید XML هم‌بس/ اتم را می‌توان با یک خط، <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>، تقویت کرد که رفتار موجود تبدیل مبتنی بر XSLT به HTML را حفظ می‌کند. این موضوع نباید بر توانایی RSS reader برای ادامه تجزیه XML تأثیر بگذارد، زیرا <script> فرزند مستقیم عنصر ریشه است.

خروجی API برای دستگاه‌های جاسازی‌شده

برخی‌از دستگاه‌های جاسازی‌شده تجاری داده‌های XML را برای استفاده کاربران در شبکه محلی اندازه‌گیری یا تولید می‌کنند. برخی‌از این دستگاه‌ها این کار را با تولید یک فید داده XML تکی انجام می‌دهند که از XSLT برای تبدیل آن به قالب HTML قابل‌خواندن برای انسان استفاده می‌کند. این کار باعث می‌شود که میانای برنامه‌سازی کاربردی مستقیماً در مرورگر قابل‌مشاهده باشد، بدون اینکه به کد اضافی در دستگاه یا مرورگر نیاز باشد.
ازآنجایی‌که این مورد استفاده بسیار مختص برنامه است، شکل راه‌حل ممکن است متفاوت باشد. برای برنامه‌هایی که کد منبع دستگاه جاسازی‌شده می‌تواند به‌روز شود، هرکدام از گزینه‌هایی که قبلاً شرح داده شد (JSON،‏ Polyfill) می‌تواند کار کند. اما به‌ویژه، به‌روزرسانی بسیاری از این دستگاه‌ها به دلایل مختلف دشوار یا غیرممکن است. در این صورت، افزونه احتمالاً بهترین گزینه است، زیرا به مرورگرهای مشتری اجازه می‌دهد بدون تغییر دستگاه، به خواندن داده‌ها دقیقاً به همان روش ادامه دهند.

قالب‌بندی تنبل برای وب‌سایت‌ها

توسعه‌دهندگان وب گاهی‌اوقات از XSLT در سمت کارخواه برای اعمال نشانه‌گذاری ارائه به نشانه‌گذاری معنایی استفاده می‌کنند که به‌عنوان زبان قالب‌بندی تنبل عمل می‌کند و از بوم‌سازگان جاوا اسکریپت جدا است.

دو راه‌حل برای این مشکل کلی‌تر وجود دارد. برای سایت موجودی که به این روش ساخته شده است، ساده‌ترین راه‌حل احتمالاً افزودن شبیه‌ساز مرورگر برای حفظ عملکرد موجود است. یا شاید تبدیل XSLT را در سمت سرور انجام دهید و HTML حاصل را به‌جای XML خام به کارخواه ارائه دهید. راهکار بلندمدت‌تر برای چنین ویژگی‌هایی، انتقال به چارچوب مدرن‌تر مبتنی بر جاوا اسکریپت یا JSON است.

اگر در Chrome با مشکل خاصی دررابطه‌با این منسوخ شدن XSLT مواجه شدید، اشکال را در اینجا گزارش کنید.

نحوه تشخیص استفاده از XSLT

به‌طور کلی، ویژگی‌های منسوخ‌شده مانند XSLT را می‌توان به چند روش در پایگاه کد شما شناسایی کرد. این بخش دو مورد از آن‌ها را شرح می‌دهد.

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 را ببینید.