הסרת XSLT כדי ליצור דפדפן מאובטח יותר

Mason Freed

Dominik Röttsches

תאריך פרסום: 29 באוקטובר 2025

‫Chrome מתכוון להוציא משימוש את XSLT ולהסיר אותו מהדפדפן. במסמך הזה מוסבר איך אפשר להעביר את הקוד לפני ההסרה בסוף שנת 2026.

‫Chromium הוציא משימוש באופן רשמי את XSLT, כולל XSLTProcessor JavaScript API והוראת העיבוד של גיליון סגנונות XML. אנחנו מתכוונים להסיר את התמיכה בגרסה 155 (17 בנובמבר 2026). גם בפרויקטים של Firefox ו-WebKit ציינו תוכניות להסרת XSLT ממנועי הדפדפן שלהם. במאמר הזה אנחנו מספקים קצת היסטוריה והקשר, מסבירים איך אנחנו מסירים את XSLT כדי להפוך את Chrome לדפדפן בטוח יותר, ומציעים דרך לבצע מיגרציה לפני שהתכונות האלה יוסרו מהדפדפן. כדאי לעיין גם בערך סטטוס הפלטפורמה של Chrome כדי לקבל את העדכונים האחרונים.

מה יוסר?

יש שני ממשקי API בדפדפן שמטמיעים XSLT, ושניהם יוסרו:

המחלקות XSLTProcessor (לדוגמה, new XSLTProcessor()).
הוראת העיבוד של XSLT (לדוגמה, <?xml-stylesheet … ?>).

ציר הזמן ב-Chrome

‫Chrome מציע את התוכנית הבאה:

‫Chrome 142 (28 באוקטובר 2025): נוספו ל-Chrome הודעות קונסולה עם אזהרה מוקדמת.
‫Chrome 143 (2 בדצמבר 2025): הוצאה רשמית משימוש של ה-API – הודעות אזהרה על הוצאה משימוש יתחילו להופיע במסוף וב-Lighthouse.
‫Chrome 145 (2 בדצמבר 2025 Canary): גרסאות Canary,‏ Dev ו-Beta יתחילו להשבית את XSLT כברירת מחדל, כהתראה מוקדמת.
‫Chrome 146 (10 במרץ 2026): מדיניות Enterprise (EP) עוברת למצב פעיל לצורך בדיקה. כך ארגונים יכולים לבדוק את ההשבתה של XSLT מוקדם, וגם להמשיך להשתמש בתכונות אחרי תאריך ההסרה.
‫Chrome 152 (25 באוגוסט 2026): גרסת מקור לניסיון (OT) תושק לבדיקות. כך אתרים יכולים להמשיך להשתמש בתכונות אחרי תאריך ההסרה.
‫Chrome 155 (17 בנובמבר 2026): ‏ XSLT מפסיק לפעול בגרסאות יציבות, עבור כל המשתמשים מלבד משתתפים בגרסת ניסיון של Origin ובמדיניות Enterprise.
‫Chrome 164 (17 באוגוסט 2027): גרסת המקור לניסיון ומדיניות Enterprise יפסיקו לפעול. פרוטוקול 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 API, שאפשר להשתמש בו כדי לעבד מסמכי XML מקומיים עם גיליונות סגנון מקומיים של XSLT.

היסטוריה של XSLT

‫XSLT הומלצה על ידי World Wide Web Consortium ‏ (W3C) ב-16 בנובמבר 1999 כשפה להמרת מסמכי XML לפורמטים אחרים, בדרך כלל HTML להצגה בדפדפני אינטרנט. לפני ההמלצה הרשמית 1.0, מיקרוסופט יזמה פעולה מוקדמת על ידי משלוח הטמעה קניינית שמבוססת על טיוטת עבודה של W3C ב-Internet Explorer 5.0, שפורסם במרץ 1999. בהתאם לתקן הרשמי, מוזילה הטמיעה תמיכה מקורית ב-XSLT 1.0 ב-Netscape 6 בסוף שנת 2000. גם בדפדפנים נפוצים אחרים, כולל Safari,‏ Opera וגרסאות מאוחרות יותר של Chrome, שולבו מעבדי XSLT 1.0 מקוריים, מה שהפך את ההמרות של XML ל-HTML בצד הלקוח לטכנולוגיית אינטרנט שימושית בתחילת שנות ה-2000.

שפת XSLT המשיכה להתפתח, ובשנת 2007 הושקה גרסה XSLT 2.0 ובשנת 2017 הושקה גרסה XSLT 3.0. בגרסאות האלה נוספו תכונות מתקדמות כמו ביטויים רגולריים, שיפורים בסוגי הנתונים והיכולת לעבד JSON. עם זאת, התמיכה בדפדפנים לא התקדמה. נכון להיום, כל המנועים העיקריים של דפדפני האינטרנט מספקים תמיכה מובנית רק ב-XSLT 1.0 המקורי משנת 1999. הקיפאון הזה, יחד עם העלייה בשימוש ב-JSON כפורמט העברה, ובספריות ובמסגרות של JavaScript (כמו jQuery,‏ React ו-Vue.js) שמציעות גמישות רבה יותר ועוצמה רבה יותר במניפולציה של DOM ובתבניות, הובילו לירידה משמעותית בשימוש ב-XSLT בצד הלקוח. הטכנולוגיות האלה שמבוססות על JavaScript החליפו במידה רבה את התפקיד של Flash בדפדפן האינטרנט.

למה צריך להסיר את XSLT?

המשך הכללת XSLT 1.0 בדפדפני אינטרנט יוצר סיכון אבטחה משמעותי ומיותר. הספריות הבסיסיות שמבצעות את ההמרות האלה, כמו libxslt (שמשמשת דפדפני Chromium), הן בסיסי קוד מורכבים של C/C++‎ שהם ישנים. קוד כזה חשוף במיוחד לנקודות תורפה שקשורות לבטיחות הזיכרון, כמו גלישת חוצץ, שעלולה להוביל להרצת קוד שרירותי. לדוגמה, בביקורות אבטחה ובכלי מעקב אחרי באגים זוהו שוב ושוב נקודות חולשה ברמת חומרה גבוהה במנתחי הנתונים האלה (למשל, ‫CVE-2025-7425 ו-CVE-2022-22834, שתיהן ב-libxslt). מכיוון ש-XSLT בצד הלקוח הוא עכשיו תכונה נישתית שמשתמשים בה לעיתים רחוקות, הספריות האלה מקבלות הרבה פחות תחזוקה ובדיקות אבטחה מאשר מנועי JavaScript מרכזיים. עם זאת, הן מייצגות משטח תקיפה ישיר ופוטנציאלי לעיבוד תוכן אינטרנט לא מהימן. למעשה, XSLT הוא המקור לכמה ניצולי פרצות אבטחה בולטים מהזמן האחרון, שממשיכים לסכן את המשתמשים בדפדפנים. סיכוני האבטחה שקשורים לתחזוקה של הפונקציונליות המיושנת והלא יציבה הזו גדולים בהרבה מהתועלת המוגבלת שלה כיום.

בנוסף, המטרה המקורית של XSLT בצד הלקוח – המרת נתונים ל-HTML שניתן לעיבוד – הוחלפה בממשקי API של 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.

‫XSLT בצד הלקוח ב-JavaScript

יש כמה ספריות XSLT בצד הלקוח (מבוססות JavaScript), אבל הגדולה ביותר היא של Saxonica (אפשר לעיין בתיעוד המקיף של Saxonica). ההטמעה הזו חורגת מההטמעה של XSLT 1.0 בדפדפני אינטרנט, ומספקת תמיכה מלאה בתקן v3.0 העדכני, ובסופו של דבר גם בתקן v4.0 שנמצא בתהליך פיתוח.

פוליפיל

יש 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, וטוען אותו באופן שקוף, ומחליף את המסמך.

Extension

יש גם תוסף ל-Chrome שאפשר להוסיף לדפדפנים נתמכים, והוא יחיל את אותו פוליפיל של 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 למצוא את הפיד אם משתמש מדביק רק את כתובת האתר, אבל הוא גם מאפשר למשתמשים אנושיים לראות את תוכן ה-HTML הרגיל בלי להתבלבל מקישור למשאב XML. הגישה הזו תואמת גם לפרדיגמה הרגילה באינטרנט, שלפיה HTML מיועד לאנשים ו-XML מיועד למכונות. כמובן שזה לא פותר את המקרה שבו למשתמש יש קישור RSS ממקור כלשהו, והוא מדביק אותו בדפדפן האינטרנט (ולא בקורא ה-RSS).

אם לא רוצים להשתמש בפתרון הזה, אפשר להשתמש ב-polyfill. כמו שצוין קודם, אפשר להוסיף שורה אחת לפיד ה-XML של RSS/Atom, ‏ <script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>, כדי לשמור על ההתנהגות הקיימת של המרה מבוססת-XSLT ל-HTML. זה לא אמור להשפיע על היכולת של קורא ה-RSS להמשיך לנתח את ה-XML, כי <script> הוא צאצא ישיר של רכיב הבסיס.

פלט של API למכשירים מוטמעים

יש מכשירים מסחריים מוטמעים שמודדים נתוני XML או יוצרים אותם בדרך אחרת, כדי שהמשתמשים ברשת המקומית יוכלו להשתמש בהם. חלק מהמכשירים האלה עושים את זה על ידי יצירה של פיד נתונים יחיד בפורמט XML, שמשתמש ב-XSLT כדי להמיר אותו לפורמט HTML שניתן לקריאה על ידי בני אדם. כך אפשר לראות את ה-API ישירות בדפדפן בלי להוסיף קוד במכשיר או בדפדפן.
מכיוון שמדובר בתרחיש שימוש ספציפי מאוד לאפליקציה, יכול להיות שהפתרון יהיה שונה. באפליקציות שבהן אפשר לעדכן את קוד המקור של המכשיר המוטמע, כל אחת מהאפשרויות שמתוארות למעלה (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 אפשר לקבל מידע נוסף על הפעלת התכונה הזו.