פורסם: 29 באוקטובר 2025
Chrome מתכוון להוציא משימוש את XSLT ולהסיר אותו מהדפדפן. במסמך הזה מוסבר איך אפשר להעביר את הקוד לפני ההסרה בסוף שנת 2026.
Chromium הוציא משימוש באופן רשמי את XSLT, כולל XSLTProcessor JavaScript API והוראות לעיבוד גיליונות סגנון של XML. אנחנו מתכוונים להסיר את התמיכה בגרסה 155 (17 בנובמבר 2026). גם בפרויקטים של Firefox ו-WebKit ציינו תוכניות להסרת XSLT ממנועי הדפדפן שלהם. במאמר הזה אנחנו מספקים קצת היסטוריה והקשר, מסבירים איך אנחנו מסירים את XSLT כדי להפוך את Chrome לדפדפן בטוח יותר, ומציעים דרך להעברה לפני שהתכונות האלה יוסרו מהדפדפן.
מה יוסר?
יש שני ממשקי API בדפדפן שמטמיעים XSLT, ושניהם יוסרו:
- המחלקות
XSLTProcessor (לדוגמה,
new XSLTProcessor()). - הוראת עיבוד XSLT
(לדוגמה,
<?xml-stylesheet … ?>).
לוח הזמנים של Chrome
Chrome מציע את התוכנית הבאה:
- Chrome 142 (28 באוקטובר 2025): נוספו ל-Chrome הודעות קונסולה עם אזהרה מוקדמת.
- Chrome 143 (2 בדצמבר 2025): הוצאה רשמית משימוש של ה-API – הודעות אזהרה על הוצאה משימוש יתחילו להופיע במסוף וב-Lighthouse.
- Chrome 148 (גרסת Canary מ-10 במרץ 2026): גרסאות Canary, Dev ו-Beta מתחילות להשבית את XSLT כברירת מחדל, כאזהרה מוקדמת.
- Chrome 152 (25 באוגוסט 2026): גרסת המקור לניסיון (OT) ומדיניות Enterprise (EP) עוברות לשלב הבדיקה. הם מאפשרים לאתרים ולחברות להמשיך להשתמש בתכונות אחרי תאריך ההסרה.
- Chrome 155 (17 בנובמבר 2026): XSLT מפסיק לפעול בגרסאות יציבות, עבור כל המשתמשים מלבד משתתפים בניסוי מקור ובמדיניות ארגונית.**
- 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.
למה צריך להסיר את 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 מציג עכשיו באנר אזהרה שמקשר ישירות לדף חיפוש תוספים, כדי לעזור למשתמשים למצוא תוסף:
תרחישים ספציפיים לדוגמה
בדיון בתקני HTML, זוהו כמה תרחישי שימוש קונקרטיים. בקטע הזה נסביר על כל אחת מהן בנפרד, כדי להמליץ על דרכים למפתחים שמפרסמים היום משאבי XML שמשתמשים ב-XSLT.
פידים של RSS ו-Atom
בפידים רבים קיימים בפורמט RSS או Atom, נעשה שימוש ב-XSLT כדי להפוך פידים גולמיים בפורמט XML לקריאים כשצופים בהם ישירות בדפדפן. תרחיש השימוש העיקרי הוא שכאשר משתמש לוחץ בטעות על קישור לפיד RSS של אתר, במקום להדביק את הקישור הזה לקורא ה-RSS שלו, הוא מקבל תגובת HTML מעוצבת שהוא יכול לקרוא, במקום קובץ ה-XML הגולמי עצמו.
יש שני תרחישים לדוגמה לשימוש ב-Google Analytics 4. הדרך הסטנדרטית לעשות את זה ב-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](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.