تمت ترجمة هذه الصفحة بواسطة Cloud Translation API‏.

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

Mason Freed

Dominik Röttsches

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

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

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

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

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

فئة XSLTProcessor (على سبيل المثال، new XSLTProcessor()).
تعليمات معالجة XSLT (على سبيل المثال، <?xml-stylesheet … ?>).

المخطط الزمني لمتصفّح Chrome

يتضمّن Chrome الخطة التالية:

‫Chrome 142 (‫28 أكتوبر 2025): تمت إضافة رسائل وحدة التحكّم الخاصة بالتحذير المبكر إلى Chrome.
‫Chrome 143 (2 ديسمبر 2025): الإيقاف النهائي لواجهة برمجة التطبيقات - ستبدأ رسائل التحذير بشأن الإيقاف النهائي في الظهور في وحدة التحكّم وفي Lighthouse.
‫Chrome 148 (إصدار Canary بتاريخ 10 مارس 2026): ستبدأ إصدارات Canary وDev وBeta في إيقاف XSLT تلقائيًا، وذلك كتحذير مبكر.
‫Chrome 152 (‫25 أغسطس 2026): سيتم إطلاق مرحلة التجربة والتقييم (OT) وسياسة المؤسسة (EP) لإجراء الاختبارات. تسمح هذه السياسات للمواقع الإلكترونية والمؤسسات بمواصلة استخدام الميزات بعد تاريخ إزالتها.
‫Chrome 155 (‫17 نوفمبر 2026): سيتوقف XSLT عن العمل في الإصدارات الثابتة لجميع المستخدمين باستثناء المشاركين في "التجربة الأصلية" و"سياسة المؤسسة".**
‫Chrome 164 (‫17 آب [أغسطس] 2027): إيقاف مرحلة التجربة والتقييم وسياسة المؤسسة تم إيقاف XSLT لجميع المستخدمين.**

ما هي XSLT؟

‫XSLT، أو تحويلات لغة أوراق الأنماط القابلة للتوسيع، هي لغة تُستخدم لتحويل مستندات XML، وعادةً إلى تنسيقات أخرى مثل HTML. يستخدم هذا التنسيق ملف أوراق أنماط XSLT لتحديد قواعد التحويل، وملف 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 المعروضة في المثال السابق، تتوفّر أيضًا واجهة برمجة تطبيقات JavaScript XSLTProcessor التي يمكن استخدامها لمعالجة مستندات 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 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، وهي ما يستخدمه جميع مطوّري الويب تقريبًا اليوم. في الواقع، لا يستخدم سوى 0.02% من عمليات تحميل صفحات الويب حاليًا لغة XSLT، ويستخدم أقل من 0.001% تعليمات معالجة XSLT.

هذا الإجراء لا يقتصر على Chrome أو Chromium، بل إنّ محركَي المتصفّحَين الرئيسيين الآخرَين يتيحان أيضًا إزالة XSLT من منصة الويب، وهما: WebKit وGecko.

لهذه الأسباب، يؤدي إيقاف XSLT نهائيًا وإزالتها إلى تقليل مساحة الهجوم في المتصفّح لجميع المستخدمين، وتبسيط منصة الويب، والسماح بتركيز موارد الهندسة على تأمين التقنيات التي تشغّل الويب الحديث فعليًا، بدون أي فقدان عملي للقدرات بالنسبة إلى المطوّرين.

تحسين أمان تحليل XML

على غرار المشاكل الخطيرة المتعلقة بالأمان في libxslt، تم مؤخرًا الإبلاغ عن مشاكل خطيرة متعلقة بالأمان في libxml2، وهي مكتبة مستخدَمة في Chromium لتحليل XML وتسلسله واختبار صحة تنسيقه. لمعالجة مشاكل الأمان المستقبلية المتعلقة بتحليل XML في Chromium، نخطّط لإيقاف استخدام libxml2 تدريجيًا واستبدال عملية تحليل XML بمكتبة تحليل XML آمنة من حيث استخدام الذاكرة ومكتوبة بلغة Rust. تجدر الإشارة إلى أنّنا لن نزيل XML من المتصفّح، بل سنزيل XSLT فقط. نحن نهدف إلى ضمان أن يكون استبدال libxml2 شفافًا تمامًا لمطوّري الويب.

كيفية نقل البيانات

تتوفّر بعض المسارات البديلة لنقل البيانات.

JSON

بالنسبة إلى المواقع الإلكترونية التي تم إنشاؤها بالكامل باستخدام XML وXSL، ليس هناك طريقة واحدة تناسب الجميع لإجراء عملية الانتقال. تشمل خيارات نقل البيانات نقل مسار معالجة XSLT إلى جهة الخادم وإرسال HTML المعروض إلى العميل، أو نقل نقاط نهاية XML API من جهة الخادم إلى JSON، وتنفيذ العرض من جهة العميل باستخدام JavaScript لتحويل JSON إلى HTML DOM وCSS.

Client-side XSLT in 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.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 ويحمّله بشكل شفاف، ما يؤدي إلى استبدال المستند.

الإضافة

تتوفّر أيضًا إضافة Chrome يمكن إضافتها إلى المتصفحات المتوافقة، وستطبّق هذه الإضافة عملية التعبئة نفسها على جميع صفحات 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](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.