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

Mason Freed
Mason Freed
X GitHub
Dominik Röttsches
Dominik Röttsches
GitHub Mastodon

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

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

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

מה אנחנו מסירים?

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

ציר הזמן ב-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): מדיניות הארגון נכנסת לשימוש לצורך בדיקה. כך ארגונים יכולים לבדוק את השבתת XSLT בשלב מוקדם, וגם להמשיך להשתמש בתכונות אחרי תאריך ההסרה.
  • ‫Chrome 152 (‏25 באוגוסט 2026): גרסת המקור לניסיון (OT) נכנסת לשימוש לצורך בדיקה. כך אתרים יכולים להמשיך להשתמש בתכונות גם אחרי תאריך ההסרה.
  • גרסה 154 של Chrome (‏22 בספטמבר 2026): גרסאות Canary, ‏Dev ו-Beta של WebView מתחילות להשבית את XSLT כברירת מחדל, כאזהרה מוקדמת.
  • ‫Chrome 158 (17 בנובמבר 2026): התכונה XSLT תפסיק לפעול בגרסאות יציבות אצל כל המשתמשים, למעט אלה שמשתתפים בגרסת מקור לניסיון או במדיניות ארגונית.
  • ‫Chrome 176 (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 שמוצגת בדוגמה הקודמת, יש גם את ה-API של XSLTProcessor ב-JavaScript, שבו אפשר להשתמש כדי לעבד מסמכי XML מקומיים עם גיליונות סגנונות מקומיים של XSLT.

ההיסטוריה של XSLT

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

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

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

ההכללה המתמשכת של XSLT 1.0 בדפדפני אינטרנט מהווה סיכון אבטחה משמעותי ומיותר. הספריות הבסיסיות שמעבדות את השינויים האלה, כמו libxslt (שמשמשת את דפדפני Chromium), הן בסיסי קוד מורכבים וישנים בשפות C/C++‎. הסוג הזה של קוד רגיש במיוחד לנקודות חולשה של בטיחות זיכרון כמו גלישות חוצץ (buffer overflow), שעלולות להוביל להרצת קוד שרירותי. לדוגמה, ביקורות אבטחה ומעקבי באגים זיהו שוב ושוב נקודות חולשה חמורות במנתחים האלה (למשל, 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 מנהלות את העיבוד של הנתונים האלה בצורה יעילה ומאובטחת. ה-toolchain המודרני הזה מפותח באופן פעיל, נהנה מההשקעה המסיבית באבטחה במנועי 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 תהיה שקופה לחלוטין למפתחי אתרים.

‫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 שעבר עיבוד ללקוח, או העברה של נקודות קצה ל-API בפורמט XML בצד השרת ל-JSON, וביצוע עיבוד בצד הלקוח באמצעות JavaScript כדי להמיר JSON ל-HTML DOM ול-CSS.

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

יש כמה ספריות XSLT בצד הלקוח (מבוססות JavaScript), אבל הגדולה ביותר היא של Saxonica (למסמכי התיעוד המקיפים של Saxonica). ההטמעה חורגת בהרבה מההטמעה של XSLT 1.0 בדפדפני אינטרנט, ומטמיעה תמיכה מלאה בתקן העדכני של גרסה 3.0, ובסופו של דבר בתקן של גרסה 4.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, וטוען אותו באופן שקוף, תוך החלפת המסמך.

Extension

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