منتشر شده: ۲۹ اکتبر ۲۰۲۵
کروم قصد دارد XSLT را از مرورگر خود حذف کند. این سند جزئیات نحوه انتقال کد شما را قبل از حذف در اواخر سال 2026 شرح می‌دهد.
کرومیوم رسماً XSLT، شامل رابط برنامه‌نویسی کاربردی جاوا اسکریپت XSLTProcessor و دستورالعمل پردازش استایل‌شیت XML را منسوخ اعلام کرده است. ما قصد داریم پشتیبانی از نسخه ۱۵۵ (۱۷ نوامبر ۲۰۲۶) را حذف کنیم. پروژه‌های فایرفاکس و وب‌کیت نیز برنامه‌هایی برای حذف XSLT از موتورهای مرورگر خود ارائه داده‌اند. این سند تاریخچه و زمینه‌ای از این موضوع را ارائه می‌دهد، توضیح می‌دهد که چگونه XSLT را برای ایمن‌تر کردن کروم حذف می‌کنیم و مسیری را برای مهاجرت قبل از حذف این ویژگی‌ها از مرورگر ارائه می‌دهد.
چه چیزی حذف می‌شود؟
دو API در مرورگر وجود دارد که XSLT را پیاده‌سازی می‌کنند و هر دو حذف می‌شوند:
- کلاس XSLTProcessor (برای مثال،
new XSLTProcessor()). - دستورالعمل پردازش XSLT (برای مثال،
<?xml-stylesheet … ?>).
تایم‌لاین برای کروم
کروم طرح زیر را دارد:
- کروم ۱۴۲ (۲۸ اکتبر ۲۰۲۵): پیام‌های هشدار اولیه به کنسول کروم اضافه شد.
- کروم ۱۴۳ (۲ دسامبر ۲۰۲۵): منسوخ شدن رسمی API - پیام‌های هشدار منسوخ شدن در کنسول و لایت‌هاوس شروع به نمایش می‌کنند.
- کروم ۱۴۸ (۱۰ مارس ۲۰۲۶، نسخه قناری): نسخه‌های قناری، توسعه‌دهندگان و بتا، به عنوان یک هشدار اولیه، به طور پیش‌فرض XSLT را غیرفعال می‌کنند.
- کروم ۱۵۲ (۲۵ آگوست ۲۰۲۶): نسخه آزمایشی Origin (OT) و Enterprise Policy (EP) برای آزمایش منتشر شدند. این نسخه‌ها به سایت‌ها و شرکت‌ها اجازه می‌دهند پس از تاریخ حذف، به استفاده از ویژگی‌های جدید ادامه دهند.
- کروم ۱۵۵ (۱۷ نوامبر ۲۰۲۶): XSLT در نسخه‌های پایدار، برای همه کاربران به جز کاربران نسخه آزمایشی Origin و شرکت‌کنندگان در سیاست سازمانی، از کار می‌افتد.**
- کروم ۱۶۴ (۱۷ آگوست ۲۰۲۷): نسخه آزمایشی Origin و سیاست سازمانی از کار افتادند. XSLT برای همه کاربران غیرفعال است.**
XSLT چیست؟
XSLT یا Extensible Stylesheet Language Transformations زبانی است که برای تبدیل اسناد XML، معمولاً به فرمت‌های دیگر مانند HTML، استفاده می‌شود. این زبان از یک فایل XSLT Stylesheet برای تعریف قوانین این تبدیل و یک فایل XML حاوی داده‌های ورودی استفاده می‌کند.
در مرورگرها، وقتی یک فایل XML دریافت می‌شود که به یک شیوه‌نامه XSLT لینک شده است، مرورگر از قوانین موجود در آن شیوه‌نامه برای تنظیم مجدد، قالب‌بندی و تبدیل داده‌های خام 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 که در مثال قبلی نشان داده شد، API جاوا اسکریپت XSLTProcessor نیز وجود دارد که می‌تواند برای پردازش اسناد XML محلی با شیوه‌نامه‌های محلی XSLT مورد استفاده قرار گیرد.
تاریخچه XSLT
XSLT در ۱۶ نوامبر ۱۹۹۹ توسط کنسرسیوم جهانی وب (W3C) به عنوان زبانی برای تبدیل اسناد XML به فرمت‌های دیگر، که معمولاً HTML برای نمایش در مرورگرهای وب است، توصیه شد. قبل از توصیه رسمی نسخه ۱.۰، مایکروسافت با ارائه یک پیاده‌سازی اختصاصی بر اساس پیش‌نویس کاری W3C در Internet Explorer 5.0 که در مارس ۱۹۹۹ منتشر شد، ابتکار عمل اولیه‌ای به خرج داد. به دنبال استاندارد رسمی، موزیلا پشتیبانی بومی 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 به عنوان یک قالب سیمی، و کتابخانه‌ها و چارچوب‌های جاوا اسکریپت (مانند jQuery، React و Vue.js) که دستکاری و قالب‌بندی DOM انعطاف‌پذیرتر و قدرتمندتری را ارائه می‌دهند، منجر به کاهش قابل توجه استفاده از XSLT سمت کلاینت شده است. نقش آن در مرورگر وب تا حد زیادی توسط این فناوری‌های مبتنی بر جاوا اسکریپت جایگزین شده است.
چرا XSLT باید حذف شود؟
ادامه‌ی استفاده از XSLT 1.0 در مرورگرهای وب، یک ریسک امنیتی قابل توجه و غیرضروری را ایجاد می‌کند. کتابخانه‌های زیربنایی که این تبدیل‌ها را پردازش می‌کنند، مانند libxslt (که توسط مرورگرهای Chromium استفاده می‌شود)، کدهای پیچیده و قدیمی C/C++ هستند. این نوع کد به طور آشکار مستعد آسیب‌پذیری‌های ایمنی حافظه مانند سرریز بافر است که می‌تواند منجر به اجرای کد دلخواه شود. به عنوان مثال، ممیزی‌های امنیتی و ردیاب‌های باگ بارها آسیب‌پذیری‌های با شدت بالا را در این تجزیه‌کننده‌ها شناسایی کرده‌اند (به عنوان مثال، CVE-2025-7425 و CVE-2022-22834 ، هر دو در libxslt). از آنجا که XSLT سمت کلاینت اکنون یک ویژگی خاص و به ندرت استفاده شده است، این کتابخانه‌ها نسبت به موتورهای اصلی جاوا اسکریپت، نگهداری و بررسی امنیتی بسیار کمتری دریافت می‌کنند، با این حال، آنها یک سطح حمله مستقیم و قوی برای پردازش محتوای وب غیرقابل اعتماد هستند. در واقع، XSLT منبع چندین سوءاستفاده امنیتی اخیر و پر سر و صدا است که همچنان کاربران مرورگر را در معرض خطر قرار می‌دهد. خطرات امنیتی حفظ این عملکرد شکننده و قدیمی بسیار بیشتر از کاربرد مدرن محدود آن است.
علاوه بر این، هدف اصلی XSLT سمت کلاینت - تبدیل داده‌ها به HTML قابل رندر - توسط APIهای جاوا اسکریپت امن‌تر، ارگونومیک‌تر و با نگهداری بهتر جایگزین شده است. توسعه وب مدرن به مواردی مانند Fetch API برای بازیابی داده‌ها (معمولاً JSON) و DOMParser API برای تجزیه ایمن رشته‌های XML یا HTML به یک ساختار DOM در جعبه شنی امن جاوا اسکریپت مرورگر متکی است. سپس چارچوب‌هایی مانند React، Vue و Svelte رندر این داده‌ها را به طور کارآمد و ایمن مدیریت می‌کنند. این زنجیره ابزار مدرن به طور فعال توسعه داده می‌شود، از سرمایه‌گذاری عظیم امنیتی در موتورهای جاوا اسکریپت بهره می‌برد و چیزی است که تقریباً همه توسعه‌دهندگان وب امروزه از آن استفاده می‌کنند. در واقع، امروزه فقط حدود 0.02٪ از بارگذاری صفحات وب در واقع از XSLT استفاده می‌کنند و کمتر از 0.001٪ از دستورالعمل‌های پردازش XSLT استفاده می‌کنند.
این اقدام فقط مختص کروم یا کرومیوم نیست: دو موتور مرورگر اصلی دیگر نیز از حذف XSLT از پلتفرم وب پشتیبانی می‌کنند: WebKit و Gecko .
به همین دلایل، منسوخ کردن و حذف XSLT سطح حمله مرورگر را برای همه کاربران کاهش می‌دهد، پلتفرم وب را ساده می‌کند و به منابع مهندسی اجازه می‌دهد تا بر ایمن‌سازی فناوری‌هایی که در واقع وب مدرن را تقویت می‌کنند، متمرکز شوند، بدون اینکه عملاً هیچ گونه از دست دادن توانایی برای توسعه‌دهندگان وجود داشته باشد.
بهبود امنیت تجزیه XML
مشابه مشکلات امنیتی شدید در libxslt، اخیراً مشکلات امنیتی شدیدی علیه libxml2 که در کرومیوم برای تجزیه، سریال‌سازی و آزمایش صحت ساختار XML استفاده می‌شود، گزارش شده است. برای رسیدگی به مشکلات امنیتی آینده در تجزیه XML در کرومیوم، قصد داریم استفاده از libxml2 را به تدریج کنار بگذاریم و تجزیه XML را با یک کتابخانه تجزیه XML امن برای حافظه که با Rust نوشته شده است، جایگزین کنیم. نکته مهم این است که ما XML را از مرورگر حذف نخواهیم کرد. در اینجا فقط XSLT برای حذف در نظر گرفته شده است. ما قصد داریم اطمینان حاصل کنیم که جایگزینی libxml2 کاملاً برای توسعه‌دهندگان وب شفاف باشد.
چگونه مهاجرت کنیم
چند مسیر جایگزین برای مهاجرت وجود دارد.
جی‌سون
برای سایت‌هایی که کاملاً بر اساس XML و XSL ساخته شده‌اند، هیچ راه یکسانی برای انتقال وجود ندارد. گزینه‌های مهاجرت شامل انتقال خط لوله پردازش XSLT به سمت سرور و ارسال HTML رندر شده به کلاینت، یا مهاجرت نقاط پایانی XML API سمت سرور به JSON و انجام رندر سمت کلاینت با استفاده از جاوا اسکریپت برای تبدیل JSON به HTML DOM و CSS است.
XSLT سمت کلاینت در جاوا اسکریپت
چند کتابخانه XSLT سمت کلاینت (مبتنی بر جاوا اسکریپت) در دسترس است، اما بزرگترین آنها تاکنون توسط Saxonica تولید شده است (به مستندات جامع Saxonica مراجعه کنید). این پیاده‌سازی فراتر از پیاده‌سازی XSLT 1.0 در مرورگرهای وب است و پشتیبانی کامل از آخرین استاندارد v3.0 و در نهایت استاندارد v4.0 در حال توسعه را پیاده‌سازی می‌کند.
پلی‌فیل
یک polyfill وجود دارد که تلاش می‌کند به کد موجود، که به پیاده‌سازی XSLT 1.0 در مرورگرهای وب بستگی دارد، اجازه دهد تا به عملکرد خود ادامه دهد، در حالی که از ویژگی‌های بومی XSLT مرورگر استفاده نمی‌کند. این polyfill در GitHub قرار دارد.
این polyfill حاوی یک جایگزین polyfill مبتنی بر WASM برای کلاس XSLTProcessor است، بنابراین کد جاوا اسکریپت موجود می‌تواند به کار خود ادامه دهد:
<script src="xslt-polyfill.min.js"></script>
<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>
این polyfill همچنین یک تابع کاربردی خودکار برای جایگزینی آسان اسناد XML که از دستورالعمل‌های پردازش XSLT استفاده می‌کنند، فراهم می‌کند:
برای یک فایل demo.xml اصلی مانند این:
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...
می‌توان یک خط اضافه کرد تا polyfill را فراخوانی کند و سند را با شیوه‌نامه 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> ، polyfill را بارگذاری می‌کند که نوع سند XML و دستورالعمل پردازش XSLT را تشخیص داده و آن را به صورت شفاف بارگذاری می‌کند و جایگزین سند می‌شود.
پسوند
همچنین یک افزونه کروم وجود دارد که می‌تواند به مرورگرهای پشتیبانی‌شده اضافه شود، که همان چندپر کردن XSLT را برای تمام صفحات XML خام که حاوی دستورالعمل‌های پردازش XSLT یا فراخوانی‌های XSLTProcessor هستند، اعمال می‌کند. این می‌تواند برای برنامه‌هایی که XML یا XSLT منبع قابل تغییر نیست، برای حفظ عملکرد استفاده شود.
به طور خاص، وقتی XSLT غیرفعال است، کروم اکنون یک بنر هشدار دهنده نشان می‌دهد که مستقیماً به صفحه جستجوی افزونه‌ها پیوند دارد تا به کاربران در یافتن افزونه کمک کند:
موارد استفاده خاص
در بحث استانداردهای HTML ، چندین مورد استفاده مشخص شناسایی شد. این بخش به طور خاص در مورد هر یک از آنها صحبت می‌کند تا مسیرهای پیش رو را برای توسعه‌دهندگانی که منابع XML را منتشر می‌کنند و امروزه از XSLT استفاده می‌کنند، توصیه کند.
فیدهای RSS و Atom
در بسیاری از فیدهای RSS یا Atom موجود، از XSLT برای خوانا کردن فیدهای خام XML توسط انسان هنگام مشاهده مستقیم در مرورگر استفاده می‌شود. کاربرد اصلی آن این است که وقتی کاربر به طور تصادفی روی لینک فید RSS یک سایت کلیک می‌کند، به جای اینکه آن لینک را در RSS خوان خود پیست کند، یک پاسخ HTML قالب‌بندی شده دریافت می‌کند که می‌تواند آن را بخواند، نه خود XML خام.
دو مسیر برای این مورد استفاده وجود دارد. روش "استاندارد" HTML برای انجام این کار، اضافه کردن <link rel="alternate" type="application/rss+xml"> به یک سایت (مبتنی بر HTML) است، نه اضافه کردن یک <a href="something.xml"> صریح (قابل مشاهده توسط کاربر) که کاربران ممکن است به طور تصادفی روی آن کلیک کنند. این راه حل به خوانندگان RSS اجازه می‌دهد تا اگر کاربر فقط URL وب‌سایت را جایگذاری کند، فید را پیدا کنند، اما همچنین به کاربران انسانی اجازه می‌دهد تا محتوای HTML معمولی را بدون سردرگمی با پیوند به یک منبع XML ببینند. این همچنین از الگوی معمول وب پیروی می‌کند که HTML برای انسان‌ها و XML برای ماشین‌ها است. البته این مورد را که کاربر فقط یک پیوند RSS از جایی "دارد" و آن را در مرورگر وب خود (به جای خواننده RSS خود) جایگذاری می‌کند، حل نمی‌کند.
وقتی این راه حل مورد نظر نباشد، polyfill مسیر دیگری ارائه می‌دهد. همانطور که قبلاً ذکر شد، فید RSS/Atom XML را می‌توان با یک خط <script src="xslt-polyfill.min.js" xmlns="[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml)"></script> تکمیل کرد، که رفتار موجود تبدیل مبتنی بر XSLT به HTML را حفظ می‌کند. این امر نباید بر توانایی RSS reader برای ادامه تجزیه XML تأثیر بگذارد، زیرا <script> فرزند مستقیم عنصر ریشه است.
خروجی API برای دستگاه‌های تعبیه‌شده
برخی از دستگاه‌های تعبیه‌شده تجاری، داده‌های XML را برای مصرف کاربران در شبکه محلی اندازه‌گیری یا تولید می‌کنند. برخی از این دستگاه‌ها این کار را با تولید یک منبع داده XML واحد انجام می‌دهند که از XSLT برای تبدیل آن به فرمت HTML قابل خواندن توسط انسان استفاده می‌کند. این امر به API اجازه می‌دهد تا مستقیماً در یک مرورگر و بدون نیاز به کد اضافی در دستگاه یا مرورگر مشاهده شود.
از آنجایی که این یک مورد استفاده بسیار خاص برای یک برنامه است، شکل راه‌حل ممکن است متفاوت باشد. برای برنامه‌هایی که کد منبع دستگاه تعبیه‌شده قابل به‌روزرسانی است، هر یک از گزینه‌هایی که قبلاً توضیح داده شد (JSON، Polyfill) می‌تواند کار کند. با این حال، به‌ویژه، به‌روزرسانی بسیاری از این دستگاه‌ها به دلایل مختلف دشوار یا غیرممکن است. در این صورت، افزونه احتمالاً بهترین گزینه است، زیرا به مرورگرهای کلاینت اجازه می‌دهد بدون تغییر دستگاه، داده‌ها را دقیقاً به همان روش قبلی بخوانند.
قالب‌بندی تنبل برای وب‌سایت‌ها
توسعه‌دهندگان وب گاهی اوقات از XSLT در سمت کلاینت برای اعمال نشانه‌گذاری ارائه به نشانه‌گذاری معنایی استفاده می‌کنند و به عنوان یک زبان قالب‌بندی تنبل که جدا از اکوسیستم جاوا اسکریپت است، عمل می‌کنند.
دو راه حل برای این مشکل کلی‌تر وجود دارد. برای یک سایت موجود که به این روش ساخته شده است، ساده‌ترین راه حل احتمالاً اضافه کردن polyfill برای حفظ قابلیت‌های موجود است. یا شاید انجام تبدیل XSLT در سمت سرور و ارائه HTML حاصل به کلاینت، به جای XML خام. راه حل بلندمدت‌تر برای چنین ویژگی‌هایی، مهاجرت به یک چارچوب مدرن‌تر جاوا اسکریپت یا مبتنی بر JSON است.