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

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

Mason Freed

Dominik Röttsches

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

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

أوقف Chromium نهائيًا ميزة XSLT، بما في ذلك الـ XSLTProcessor JavaScript API وتعليمات معالجة 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): سياسة المؤسسة (EP) يتم إطلاقها لاختبارها. يسمح هذا للمؤسسات باختبار إيقاف XSLT نهائيًا في وقت مبكر، كما سيسمح لها بمواصلة استخدام الميزات بعد تاريخ الإزالة.
الإصدار 152 من Chrome (25 أغسطس 2026): يتم إطلاق مرحلة التجربة والتقييم (OT) لاختبارها. يسمح هذا للمواقع الإلكترونية بمواصلة استخدام الميزات بعد تاريخ الإزالة.
الإصدار 158 من Chrome (17 نوفمبر 2026): يتوقف XSLT عن العمل في الإصدارات الثابتة لجميع المستخدمين باستثناء المشاركين في "مرحلة التجربة والتقييم" و"سياسة المؤسسة".
الإصدار 176 من Chrome (17 أغسطس 2027): تتوقف "مرحلة التجربة والتقييم" و"سياسة المؤسسة" عن العمل. ويتم إيقاف 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" 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 المعروضة في المثال السابق، هناك أيضًا XSLTProcessor واجهة برمجة تطبيقات JavaScript التي يمكن استخدامها لمعالجة مستندات XML المحلية باستخدام أوراق أنماط XSLT المحلية.

سجلّ لغة XSLT

أوصت رابطة الشبكة العالمية (W3C) بلغة XSLT في 16 نوفمبر، 1999 كلغة لتحويل مستندات XML إلى تنسيقات أخرى، وأكثرها شيوعًا HTML للعرض في متصفّحات الويب. قبل التوصية الرسمية بالإصدار 1.0، اتخذت Microsoft مبادرة مبكرة من خلال شحن تنفيذ خاص يستند إلى مسودة عمل من رابطة الشبكة العالمية في 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" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content 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 قيد التطوير.

حشو بوليستر

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

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

<script src="xslt-polyfill.min.js"></script>

<script>
const xsltProcessor = new XSLTProcessor();
xsltProcessor.importStylesheet(xsltDoc);
const fragment = xsltProcessor.transformToFragment(xmlDoc, document);
</script>

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

بالنسبة إلى ملف demo.xml الأصلي على النحو التالي:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl"?>
<ROOT>
...content...

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

الإضافة

هناك أيضًا إضافة Chrome extension يمكن إضافتها إلى المتصفّحات المتوافقة، والتي ستطبّق حشو البوليستر نفسه لـ 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).

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

إنشاء النماذج المؤجل للمواقع الإلكترونية

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

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