تستخدم Google تكنولوجيا الذكاء الاصطناعي لترجمة المحتوى إلى لغتك المفضّلة، وقد تتضمّن بعض الأخطاء.

إزالة XSLT لتوفير متصفّح أكثر أمانًا

Mason Freed

Dominik Röttsches

تاريخ النشر: 29 أكتوبر 2025

ينوي Chrome إيقاف ميزة XSLT نهائيًا وإزالتها من المتصفّح. يوضّح هذا المستند كيفية نقل الرمز البرمجي قبل إزالة هذه الميزة في أواخر عام 2026.

أوقف Chromium رسميًا ميزة XSLT، بما في ذلك واجهة برمجة التطبيقات XSLTProcessor JavaScript وتعليمات معالجة XSLT. وننوي إيقاف الدعم من الإصدار 158 (17 نوفمبر 2026). أشار مشروعا Firefox وWebKit أيضًا إلى خطط لإزالة XSLT من محركات المتصفّحات الخاصة بهما. يقدّم هذا المستند بعض المعلومات عن تاريخ هذه الميزات وسياقها، ويشرح كيفية إزالة XSLT لجعل Chrome أكثر أمانًا، ويوفّر مسارًا لنقل البيانات قبل إزالة هذه الميزات من المتصفّح. للاطّلاع على آخر الأخبار، يمكنك أيضًا مراجعة إدخال حالة النظام الأساسي Chrome.

ما هي الميزات التي ستتم إزالتها؟

تتوفّر واجهتا برمجة تطبيقات في المتصفّح تنفّذان XSLT، وستتم إزالتهما:

فئة XSLTProcessor (على سبيل المثال، new XSLTProcessor()).
تعليمات معالجة XSLT (على سبيل المثال، <?xml-stylesheet type="text/xsl" ... ?>)

"المخطط الزمني" في Chrome

لدى Chrome الخطة التالية:

الإصدار 142 من Chrome‏ (28 أكتوبر 2025): ستتم إضافة رسائل تحذير مبكر إلى وحدة تحكّم Chrome.
الإصدار 143 من Chrome‏ (2 ديسمبر 2025): الإيقاف النهائي لواجهة برمجة التطبيقات - ستبدأ رسائل التحذير بشأن الإيقاف النهائي في الظهور في وحدة التحكّم وفي Lighthouse.
الإصدار 145 من Chrome (في 2 ديسمبر 2025 Canary): تبدأ إصدارات Canary وDev وBeta في إيقاف XSLT تلقائيًا كتحذير مبكر.
الإصدار 146 من Chrome‏ (10 مارس 2026): يتم إطلاق سياسة Enterprise‏ (EP) لاختبارها. يتيح ذلك للمؤسسات اختبار إيقاف XSLT مبكرًا، كما يتيح لها مواصلة استخدام الميزات بعد تاريخ الإزالة.
الإصدار 152 من Chrome‏ (25 أغسطس 2026): سيتم إطلاق مرحلة التجربة والتقييم للاختبار. ويتيح ذلك للمواقع الإلكترونية مواصلة استخدام الميزات بعد تاريخ الإزالة.
الإصدار 154 من Chrome‏ (22 سبتمبر 2026): ستبدأ إصدارات Canary وDev وBeta من Webview في إيقاف XSLT تلقائيًا كتحذير مبكر.
الإصدار 158 من Chrome‏ (17 نوفمبر 2026): يتوقف XSLT عن العمل في الإصدارات الثابتة لجميع المستخدمين باستثناء المشاركين في "مرحلة التجربة والتقييم" و"سياسة المؤسسة".
الإصدار 176 من Chrome‏ (17 أغسطس 2027): سيتوقف عمل "مرحلة التجربة والتقييم" و"سياسة المؤسسة". يتم إيقاف XSLT لجميع المستخدمين.

ما هي لغة XSLT؟

‫XSLT، أو "تحويلات لغة ورقة الأنماط القابلة للامتداد"، هي لغة تُستخدم لتحويل مستندات 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 التي يمكن استخدامها لمعالجة مستندات XML المحلية باستخدام أوراق أنماط XSLT المحلية.

تاريخ XSLT

أوصت رابطة الشبكة العالمية (W3C) باستخدام XSLT في 16 نوفمبر 1999 كلغة لتحويل مستندات XML إلى تنسيقات أخرى، وأكثرها شيوعًا HTML للعرض في متصفحات الويب. قبل إصدار التوصية الرسمية 1.0، اتخذت Microsoft مبادرة مبكرة من خلال شحن تنفيذ خاص يستند إلى مسودة عمل W3C في Internet Explorer 5.0، الذي تم إصداره في مارس 1999. باتّباع المعيار الرسمي، نفّذت Mozilla دعمًا أصليًا للغة XSLT 1.0 في Netscape 6 في أواخر عام 2000. أضافت أيضًا المتصفحات الرئيسية الأخرى، بما في ذلك Safari وOpera والإصدارات الأحدث من Chrome، معالجات XSLT 1.0 مدمجة، ما جعل تحويلات XML إلى HTML من جهة العميل تقنية ويب قابلة للتطبيق في أوائل العقد الأول من القرن الحادي والعشرين.

استمرّت لغة XSLT في التطوّر، مع إصدار XSLT 2.0 في عام 2007 وXSLT 3.0 في عام 2017، ما أدى إلى تقديم ميزات فعّالة مثل التعبيرات العادية وأنواع البيانات المحسّنة والقدرة على معالجة JSON. ومع ذلك، ظلّت ميزة التوافق مع المتصفّح راكدة. في الوقت الحالي، توفّر جميع محرّكات متصفّحات الويب الرئيسية دعمًا أصليًا فقط للإصدار الأصلي من XSLT 1.0 الذي تم إطلاقه في عام 1999. وقد أدى هذا الركود في التطوير، إلى جانب انتشار استخدام JSON كتنسيق لنقل البيانات، ومكتبات وأُطر عمل JavaScript (مثل jQuery وReact وVue.js) التي توفّر طرقًا أكثر مرونة وقوة للتعامل مع نموذج DOM وإنشاء النماذج، إلى تراجع كبير في استخدام XSLT من جهة العميل. وقد حلت هذه التقنيات المستندة إلى JavaScript محل دور XSLT داخل متصفح الويب إلى حد كبير.

لماذا يجب إزالة XSLT؟

إنّ استمرار تضمين XSLT 1.0 في متصفحات الويب يشكّل خطرًا أمنيًا كبيرًا وغير ضروري. إنّ المكتبات الأساسية التي تعالج عمليات التحويل هذه، مثل libxslt (التي تستخدمها متصفّحات Chromium)، هي قواعد رموز برمجية قديمة ومعقدة مكتوبة بلغة C/C++‎. هذا النوع من الرموز البرمجية معروف بقابليته للتأثر بثغرات سلامة الذاكرة، مثل تجاوز سعة المخزن المؤقت، والتي قد تؤدي إلى تنفيذ رموز برمجية عشوائية. على سبيل المثال، رصدت عمليات التدقيق الأمني وأدوات تتبُّع الأخطاء بشكل متكرر ثغرات أمنية شديدة الخطورة في هذه المحللات اللغوية (مثل CVE-2025-7425 وCVE-2022-22834، وكلاهما في libxslt). ونظرًا إلى أنّ XSLT من جهة العميل أصبحت ميزة متخصّصة ونادرة الاستخدام، تحظى المكتبات المرتبطة بها بمستوى صيانة وتدقيق أمني أقل بكثير مقارنةً بمحركات JavaScript الأساسية. ومع ذلك، فإنها تشكل مساحة هجوم مباشرة وخطيرة عند معالجة محتوى على الويب غير موثوق به. في الواقع، كانت ميزة XSLT مصدرًا لعدد من الثغرات الأمنية البارزة في الآونة الأخيرة، والتي لا تزال تُعرّض مستخدمي المتصفحات للخطر. إنّ المخاطر الأمنية الناتجة عن الحفاظ على هذه الوظيفة القديمة والهشة تفوق بكثير فائدتها المحدودة في الوقت الحالي.

علاوةً على ذلك، تم استبدال الغرض الأصلي من XSLT من جهة العميل، وهو تحويل البيانات إلى HTML قابل للعرض، بواجهات برمجة تطبيقات JavaScript أكثر أمانًا وسهولة في الاستخدام وتتم صيانتها بشكل أفضل. يعتمد تطوير الويب الحديث على عناصر مثل واجهة برمجة التطبيقات Fetch API لاسترداد البيانات (عادةً بتنسيق JSON) وواجهة برمجة التطبيقات DOMParser API لتحليل سلاسل XML أو HTML بأمان إلى بنية DOM ضمن بيئة JavaScript الآمنة في المتصفّح. بعد ذلك، تتولى أُطر العمل، مثل React وVue وSvelte، إدارة عرض هذه البيانات بكفاءة وأمان. يتم تطوير سلسلة الأدوات الحديثة هذه بشكل نشط، وتستفيد من الاستثمار الأمني الهائل في محركات JavaScript، وهي ما يستخدمه جميع مطوّري تطبيقات الويب تقريبًا اليوم. في الواقع، يتم استخدام XSLT في حوالي %0.02 فقط من عمليات تحميل صفحات الويب اليوم، ويتم استخدام تعليمات معالجة XSLT في أقل من %0.001 من هذه العمليات.

لا يقتصر هذا الإجراء على 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 من جهة الخادم إلى JSON، وإجراء العرض من جهة العميل باستخدام JavaScript لتحويل JSON إلى HTML DOM وCSS.

‫XSLT من جهة العميل في JavaScript

تتوفّر بعض مكتبات XSLT من جهة العميل (المستندة إلى JavaScript)، ولكنّ أكبر مكتبة على الإطلاق هي التي تنتجها شركة Saxonica (يمكنك الاطّلاع على المستندات الشاملة لشركة Saxonica). يتجاوز هذا التنفيذ بكثير تنفيذ XSLT 1.0 في متصفحات الويب، إذ يوفّر دعمًا كاملاً لأحدث معيار v3.0، وفي النهاية معيار v4.0 قيد التطوير.

Polyfill

يتوفّر polyfill يحاول السماح للرمز الحالي، الذي يعتمد على عمليات تنفيذ XSLT 1.0 في متصفّحات الويب، بمواصلة العمل بدون استخدام ميزات XSLT الأصلية من المتصفّح. يتوفّر الرمز polyfill على GitHub.

يحتوي الـ polyfill على بديل وظيفي مستند إلى WASM لفئة XSLTProcessor، لذا يمكن أن يستمر رمز JavaScript الحالي في العمل كما هو:

<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

يوفّر polyfill أيضًا دالة خدمية تلقائية تتيح بسهولة استبدال مستندات XML التي تستخدم تعليمات معالجة XSLT:

بالنسبة إلى ملف demo.xml أصلي مثل هذا:

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

يمكن إضافة سطر واحد لاستدعاء polyfill وتحويل المستند باستخدام ورقة أنماط 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> الجديد الـ polyfill الذي يرصد نوع مستند XML وتعليمات معالجة XSLT ويحمّله بشكل شفاف، ما يؤدي إلى استبدال المستند.

الإضافة

تتوفّر أيضًا إضافة Chrome يمكن إضافتها إلى المتصفّحات المتوافقة، وستطبّق polyfill نفسه لـ XSLT على جميع صفحات XML الأولية التي تحتوي على تعليمات معالجة XSLT أو طلبات إلى XSLTProcessor. ويمكن استخدام ذلك في التطبيقات التي لا يمكن فيها تغيير ملف XML أو XSLT المصدر، وذلك للحفاظ على الوظائف.

على وجه التحديد، عند إيقاف XSLT، يعرض Chrome الآن بانر تحذيريًا يتضمّن رابطًا مباشرًا إلى صفحة بحث عن الإضافات، لمساعدة المستخدمين في العثور على إضافة:

الرسالة التي تظهر في Chrome عند رصد 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"></script>، والذي سيحافظ على السلوك الحالي للتحويل المستند إلى XSLT إلى HTML. من المفترض ألا يؤثر ذلك في قدرة قارئ RSS على مواصلة تحليل ملف XML، لأنّ <script> هو عنصر فرعي مباشر للعنصر الجذر.

مخرجات واجهة برمجة التطبيقات للأجهزة المضمّنة

تقيس بعض الأجهزة التجارية المضمّنة بيانات XML أو تنشئها بطريقة أخرى ليستخدمها المستخدمون على الشبكة المحلية. وتقوم بعض هذه الأجهزة بذلك عن طريق إنشاء خلاصة بيانات XML واحدة تستخدم XSLT لتحويلها إلى تنسيق HTML يمكن لشخص عادي قراءته. يتيح ذلك عرض واجهة برمجة التطبيقات مباشرةً في المتصفّح بدون الحاجة إلى رمز إضافي على الجهاز أو في المتصفّح.
بما أنّ هذه الحالة خاصة جدًا بالتطبيق، قد يختلف شكل الحلّ. بالنسبة إلى التطبيقات التي يمكن فيها تحديث الرمز المصدر للجهاز المضمّن، يمكن استخدام أي من الخيارات الموضّحة سابقًا (JSON وPolyfill). ومع ذلك، يصعب أو يستحيل تحديث العديد من هذه الأجهزة لأسباب مختلفة. في هذه الحالة، من المرجّح أن تكون الإضافة هي الخيار الأفضل، لأنّها تتيح لمتصفّحات العملاء مواصلة قراءة البيانات بالطريقة نفسها تمامًا، بدون تعديل الجهاز.

نماذج التحميل الكسول للمواقع الإلكترونية

يستخدم مطوِّرو تطبيقات الويب أحيانًا XSLT من جهة العميل لتطبيق ترميز العرض على الترميز الدلالي، وتعمل هذه التكنولوجيا كلغة نماذج كسولة منفصلة عن منظومة JavaScript المتكاملة.

هناك حلّان لهذه المشكلة الأكثر عمومية. بالنسبة إلى المواقع الإلكترونية الحالية التي تم إنشاؤها بهذه الطريقة، فإنّ الحل الأسهل هو إضافة polyfill للحفاظ على الوظائف الحالية. أو يمكنك إجراء تحويل XSLT على جانب الخادم، وعرض ملف HTML الناتج للعميل بدلاً من ملف XML الأولي. أما الحلّ الطويل الأجل لهذه المواقع الإلكترونية، فيتمثّل في الانتقال إلى إطار عمل أكثر حداثة يستند إلى JavaScript أو 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 هذه لمزيد من المعلومات حول كيفية تفعيل هذه الميزة.