Daha güvenli bir tarayıcı için XSLT'yi kaldırma

Mason Freed
Mason Freed
Dominik Röttsches
Dominik Röttsches

Yayınlanma tarihi: 29 Ekim 2025

Chrome, XSLT desteğini sonlandırmayı ve bu özelliği tarayıcıdan kaldırmayı planlıyor. Bu belgede, 2026'nın sonlarında kaldırılmadan önce kodunuzu nasıl taşıyabileceğiniz ayrıntılı olarak açıklanmaktadır.

Chromium, XSLTProcessor JavaScript API ve XSLT işleme talimatı dahil olmak üzere XSLT desteğini resmen sonlandırdı. 158 sürümünden (17 Kasım 2026) itibaren desteği kaldırmayı planlıyoruz. Firefox ve WebKit projeleri de XSLT'yi tarayıcı motorlarından kaldırmayı planladıklarını belirtmiştir. Bu belgede, geçmiş ve bağlam hakkında bilgi verilmekte, Chrome'u daha güvenli hale getirmek için XSLT'nin nasıl kaldırıldığı açıklanmakta ve bu özellikler tarayıcıdan kaldırılmadan önce geçiş yapma yolu sunulmaktadır. En son güncellemeler için Chrome Platform Durumu girişine de bakın.

Neler kaldırılıyor?

Tarayıcıda XSLT'yi uygulayan iki API vardır ve her ikisi de kaldırılmaktadır:

Chrome için Zaman Çizelgesi

Chrome'un aşağıdaki planı vardır:

  • Chrome 142 (28 Ekim 2025): Chrome'a erken uyarı konsolu mesajları eklendi.
  • Chrome 143 (2 Aralık 2025): API'nin resmi olarak desteğinin sonlandırılması. Desteğin sonlandırılmasıyla ilgili uyarı mesajları konsolda ve Lighthouse'ta gösterilmeye başlar.
  • Chrome 145 (2 Aralık 2025 Canary): Canary, Yeni Geliştirilenler ve Beta sürümlerinde, erken uyarı olarak XSLT varsayılan olarak devre dışı bırakılmaya başlanır.
  • Chrome 146 (10 Mart 2026): Kurumsal politika (EP), test için kullanıma açılıyor. Bu sayede kuruluşlar, XSLT'yi devre dışı bırakmayı erken aşamada test edebilir ve özellikleri kaldırılma tarihinden sonra da kullanmaya devam edebilir.
  • Chrome 152 (25 Ağustos 2026): Kaynak denemesi (OT), test için kullanıma açılıyor. Bu sayede siteler, özellikleri kaldırılma tarihinden sonra da kullanmaya devam edebilir.
  • Chrome 158 (17 Kasım 2026): XSLT, kaynak denemesi ve kurumsal politika katılımcıları dışındaki tüm kullanıcılar için kararlı sürümlerde çalışmayı durdurur.
  • Chrome 176 (17 Ağustos 2027): Kaynak denemesi ve kurumsal politika artık işlevini yitirir. XSLT, tüm kullanıcılar için devre dışı bırakılır.

XSLT nedir?

XSLT veya Genişletilebilir Stil Sayfası Dil Dönüşümleri, XML dokümanlarını dönüştürmek için kullanılan bir dildir. Bu dokümanlar genellikle HTML gibi diğer biçimlere dönüştürülür. Bu dönüşümün kurallarını tanımlamak için bir XSLT stil sayfası dosyası ve giriş olarak kullanılan verileri içeren bir XML dosyası kullanılır.

Tarayıcılarda, bir XSLT stil sayfasına bağlanan bir XML dosyası alındığında tarayıcı, ham XML verilerini yeniden düzenlemek, biçimlendirmek ve dönüştürmek için bu stil sayfasındaki kuralları kullanarak kullanıcı için oluşturulabilecek yapılandırılmış bir sayfa (genellikle HTML) oluşturur.

Örneğin, bir XSLT stil sayfası aşağıdaki XML girişini alabilir:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="demo.xsl" ?>
<page>
 <message>
  Hello World.
 </message>
</page>

ve şu XSL stil sayfası:

<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>

ve tarayıcının görüntülemesi için bunları şu HTML'ye dönüştürür: HTML

<body>
  <p>Message: Hello World.</p>
</body>

Önceki örnekte gösterilen XSL işleme talimatına ek olarak, yerel XML belgelerini yerel XSLT stil sayfalarıyla işlemek için kullanılabilecek XSLTProcessor JavaScript API'si de vardır.

XSLT'nin geçmişi

XSLT, World Wide Web Consortium (W3C) tarafından 16 Kasım 1999'da XML belgelerini diğer biçimlere (en yaygın olarak web tarayıcılarında görüntüleme için HTML) dönüştürme dili olarak önerilmiştir. Microsoft, resmi 1.0 önerisinden önce 1999 Mart'ta yayınlanan Internet Explorer 5.0'da W3C çalışma taslağına dayalı tescilli bir uygulama göndererek erken bir girişimde bulunmuştu. Mozilla, resmi standarda uyarak 2000'in sonlarında Netscape 6'da yerel XSLT 1.0 desteğini uygulamaya koydu. Safari, Opera ve sonraki Chrome sürümleri de dahil olmak üzere diğer büyük tarayıcılar, yerel XSLT 1.0 işlemcilerini dahil etti. Bu sayede, 2000'li yılların başında istemci tarafında XML'den HTML'ye dönüşümler uygulanabilir bir web teknolojisi haline geldi.

XSLT dili, 2007'de XSLT 2.0 ve 2017'de XSLT 3.0 sürümlerinin yayınlanmasıyla gelişmeye devam etti. Bu sürümlerde normal ifadeler, geliştirilmiş veri türleri ve JSON işleme gibi güçlü özellikler kullanıma sunuldu. Ancak tarayıcı desteği duraksadı. Günümüzde, tüm büyük web tarayıcısı motorları yalnızca 1999'dan beri orijinal XSLT 1.0 için yerel destek sağlamaktadır. Bu gelişim eksikliği, JSON'un kablo biçimi olarak kullanımının artması ve daha esnek ve güçlü DOM manipülasyonu ile şablon oluşturma sunan JavaScript kitaplıkları ve çerçevelerinin (ör. jQuery, React ve Vue.js) yükselişiyle birleşince istemci taraflı XSLT kullanımında önemli bir düşüşe yol açtı. Web tarayıcısındaki rolü, yerini büyük ölçüde bu JavaScript tabanlı teknolojilere bıraktı.

XSLT neden kaldırılmalıdır?

XSLT 1.0'ın web tarayıcılarına dahil edilmeye devam etmesi önemli ve gereksiz bir güvenlik riski oluşturuyor. Bu dönüşümleri işleyen temel kitaplıklar (ör. libxslt, Chromium tarayıcıları tarafından kullanılır) karmaşık ve eski C/C++ kod tabanlarıdır. Bu tür kodlar, arabellek taşması gibi rastgele kod yürütmeye neden olabilen bellek güvenliği açıklarına karşı hassasiyetiyle bilinir. Örneğin, güvenlik denetimleri ve hata izleyiciler, bu ayrıştırıcılarda (ör. CVE-2025-7425 ve CVE-2022-22834, her ikisi de libxslt'de) tekrar tekrar yüksek önem düzeyli güvenlik açıkları tespit etti. İstemci taraflı XSLT artık nadiren kullanılan niş bir özellik haline geldiğinden, bu kitaplıklar temel JavaScript motorlarına kıyasla çok daha az bakım ve güvenlik incelemesi görmektedir. Buna rağmen, güvenilmeyen web içeriklerinin işlenmesi konusunda doğrudan ve güçlü bir saldırı yüzeyi oluşturmaya devam etmektedir. Nitekim XSLT, tarayıcı kullanıcılarını riske atmaya devam eden, son dönemdeki pek çok önemli güvenlik açığının kaynağıdır. Bu kırılgan ve eski işlevselliği sürdürmenin güvenlik riskleri, sınırlı modern faydasından çok daha fazladır.

Ayrıca, istemci tarafı XSLT'nin orijinal amacı olan verileri oluşturulabilir HTML'ye dönüştürme işlevi, daha güvenli, daha ergonomik ve daha iyi bakımı yapılan JavaScript API'leri tarafından geçersiz kılınmıştır. Modern web geliştirme, veri (genellikle JSON) almak için Fetch API ve XML veya HTML dizelerini tarayıcının güvenli JavaScript sanal alanında bir DOM yapısına güvenli bir şekilde ayrıştırmak için DOMParser API gibi öğelere dayanır. React, Vue ve Svelte gibi çerçeveler daha sonra bu verilerin oluşturulmasını verimli ve güvenli bir şekilde yönetir. Bu modern araç zinciri aktif olarak geliştirilir, JavaScript motorlarına yapılan büyük güvenlik yatırımından yararlanır ve günümüzde neredeyse tüm web geliştiricileri tarafından kullanılır. Gerçekten de günümüzde web sayfası yüklemelerinin yalnızca yaklaşık %0, 02'sinde XSLT kullanılmakta olup XSLT işleme talimatlarını kullananların oranı%0, 001'den düşüktür.

Bu yalnızca Chrome veya Chromium'a özgü bir işlem değildir. Diğer iki büyük tarayıcı motoru da XSLT'nin web platformundan kaldırılmasını destekler: WebKit, Gecko.

Bu nedenlerden dolayı XSLT desteğinin sonlandırılması ve bu teknolojinin kaldırılması, tarayıcının saldırı yüzeyini tüm kullanıcılar için azaltır, web platformunu basitleştirir ve mühendislik kaynaklarının, geliştiriciler için pratik bir özellik kaybı olmadan modern web'e güç veren teknolojileri güvence altına almaya odaklanmasına olanak tanır.

XML ayrıştırma güvenliğini iyileştirme

libxslt'deki ciddi güvenlik sorunlarına benzer şekilde, XML'in iyi biçimlendirilmiş olup olmadığını ayrıştırmak, seri hale getirmek ve test etmek için Chromium'da kullanılan libxml2'ye karşı da ciddi güvenlik sorunları yakın zamanda bildirildi. Chromium'da XML ayrıştırmayla ilgili gelecekteki güvenlik sorunlarını gidermek için libxml2 kullanımını aşamalı olarak sonlandırmayı ve XML ayrıştırmayı Rust ile yazılmış, bellek açısından güvenli bir XML ayrıştırma kitaplığıyla değiştirmeyi planlıyoruz. Önemli bir nokta olarak, tarayıcıdan XML'yi kaldırmayacağız. Yalnızca XSLT'nin kaldırılması değerlendiriliyor. libxml2'nin değiştirilmesinin web geliştiriciler için tamamen şeffaf olmasını sağlamayı amaçlıyoruz.

XML + CSS kaldırılmıyor

XSLT'nin (<?xml-stylesheet type="text/xsl" ... ?>) desteğinin sonlandırılması ile CSS ile kullanıldığında desteklenmeye devam eden <?xml-stylesheet ... ?> işleme talimatının kendisi arasında ayrım yapmak önemlidir. HTML'de olduğu gibi, ham verilerinize standart düzen ve tasarım kuralları uygulamak için type="text/css" ile işleme talimatını kullanmaya devam edebilirsiniz. Örneğin:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/css" href="styles.css"?>
<root>
  <item>Content here</item>
</root>

Taşıma işlemi nasıl yapılır?

Taşıma için birkaç alternatif yol vardır.

JSON

Tamamen XML ve XSL üzerine kurulu sitelerde geçiş için herkese uygun tek bir yöntem yoktur. Taşıma seçenekleri arasında XSLT işleme ardışık düzenini sunucu tarafına taşıma ve oluşturulan HTML'yi istemciye gönderme ya da sunucu tarafı XML API uç noktalarını JSON'a taşıma ve JSON'ı HTML DOM'a ve CSS'ye dönüştürmek için JavaScript kullanarak istemci taraflı oluşturma gerçekleştirme yer alır.

JavaScript'te istemci tarafı XSLT

İstemci taraflı (JavaScript tabanlı) birkaç XSLT kitaplığı mevcuttur ancak en büyüğü Saxonica tarafından üretilir (Saxonica'nın kapsamlı dokümanlarını inceleyin). Bu uygulama, web tarayıcılarındaki XSLT 1.0 uygulamasının çok ötesine geçerek en son v3.0 standardı ve nihayetinde devam eden v4.0 standardı için tam destek sunar.

Polyfill

Tarayıcının yerel XSLT özelliklerini kullanmadan, XSLT 1.0'ın web tarayıcısı uygulamalarına bağlı olan mevcut kodun çalışmaya devam etmesine izin vermeye çalışan bir çoklu doldurma vardır. Polyfill GitHub'da yer alır.

Polyfill, XSLTProcessor sınıfı için işlevsel bir WASM tabanlı polyfill değiştirme içerir. Bu nedenle, mevcut JavaScript kodu olduğu gibi çalışmaya devam edebilir:

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

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

Polyfill, XSLT işleme talimatlarını kullanan XML belgelerini kolayca değiştirmek için otomatik bir yardımcı işlev de sağlar:

Şuna benzer bir orijinal demo.xml dosya için:

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

Polyfill'i çağırmak ve dokümanı referans verilen XSLT stil sayfasıyla dönüştürmek için bir satır eklenebilir:

<?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...

Bu durumda, yeni <script> öğesi, XML doküman türünü ve XSLT işleme talimatını algılayan ve dokümanı değiştirerek şeffaf bir şekilde yükleyen polyfill'i yükler.

Uzantı

Desteklenen tarayıcılara eklenebilen bir Chrome uzantısı da vardır. Bu uzantı, XSLT işleme talimatları veya XSLTProcessor çağrıları içeren tüm ham XML sayfalarına aynı XSLT polyfill'ini uygular. Bu, işlevselliği korumak için kaynak XML veya XSLT'nin değiştirilemediği uygulamalarda kullanılabilir.

Özellikle XSLT devre dışı bırakıldığında Chrome artık kullanıcıların bir uzantı bulmasına yardımcı olmak için doğrudan bir uzantı arama sayfasına bağlantı veren bir uyarı banner'ı gösteriyor:

xslt algılandığında Chrome'da gösterilen mesaj.

Belirli kullanım alanları

HTML standartlarındaki tartışmada birkaç somut kullanım alanı belirlendi. Bu bölümde, bugün XSLT kullanan XML kaynakları yayınlayan geliştiricilere ilerleme yolları önermek için her biri hakkında ayrıntılı bilgi verilmektedir.

RSS ve Atom Feed'leri

Mevcut birçok RSS veya Atom feed'inde, ham XML feed'lerinin doğrudan bir tarayıcıda görüntülendiğinde insanlar tarafından okunabilir hale getirilmesi için XSLT kullanılır. Birincil kullanım alanı, kullanıcının bir sitenin RSS feed'i bağlantısını yanlışlıkla tıkladığında bu bağlantıyı RSS okuyucusuna yapıştırmak yerine, okuyabileceği biçimlendirilmiş bir HTML yanıtı almasıdır.

Bu kullanım alanında iki seçenek vardır. Bunu yapmanın "standart" HTML yolu, kullanıcıların yanlışlıkla tıklayabileceği açık (kullanıcı tarafından görülebilen) bir <a href="something.xml"> eklemek yerine (HTML tabanlı) bir siteye <link rel="alternate" type="application/rss+xml"> eklemektir. Bu çözüm, bir kullanıcı yalnızca web sitesi URL'sini yapıştırdığında RSS okuyucuların feed'i bulmasına olanak tanır. Ayrıca, kullanıcıların bir XML kaynağına bağlantıdan kafası karışmadan normal HTML içeriğini görmesine de olanak tanır. Bu, HTML'nin insanlar, XML'nin ise makineler için olduğu normal web paradigmasına da uygundur. Elbette bu, kullanıcının bir yerden aldığı RSS bağlantısını RSS okuyucusu yerine web tarayıcısına yapıştırdığı durumu çözmez.

Bu çözüm istenmediğinde ise polyfill başka bir yol sunar. Daha önce belirtildiği gibi, RSS/Atom XML feed'i bir satırla (<script src="xslt-polyfill.min.js" xmlns="http://www.w3.org/1999/xhtml"></script>) artırılabilir. Bu satır, XSLT tabanlı HTML'ye dönüştürmenin mevcut davranışını korur. <script>, kök öğenin doğrudan alt öğesi olduğundan bu durum, RSS okuyucunun XML'yi ayrıştırmaya devam etme özelliğini etkilemez.

Yerleştirilmiş cihazlar için API çıkışı

Bazı ticari yerleştirilmiş cihazlar, yerel ağdaki kullanıcıların tüketmesi için XML verilerini ölçer veya başka bir şekilde oluşturur. Bu cihazlardan bazıları, XSLT kullanarak tek bir XML veri feed'i oluşturup bunu okunabilir bir HTML biçimine dönüştürerek bu işlemi yapar. Bu sayede API, cihazda veya tarayıcıda ek koda gerek kalmadan doğrudan tarayıcıda görüntülenebilir.
Bu, uygulamaya özel bir kullanım alanı olduğundan çözümün şekli değişebilir. Yerleştirilmiş cihazın kaynak kodunun güncellenebildiği uygulamalarda, daha önce açıklanan seçeneklerden herhangi biri (JSON, Polyfill) kullanılabilir. Ancak özellikle bu tür cihazların çoğu, çeşitli nedenlerle güncellenemez veya güncellenmesi zordur. Bu durumda, istemci tarayıcıların cihazı değiştirmeden verileri tam olarak aynı şekilde okumaya devam etmesine olanak tanıdığı için uzantı büyük olasılıkla en iyi seçenektir.

Web siteleri için tembel şablon oluşturma

Web geliştiriciler bazen sunum işaretlemesini anlamsal işaretlemeye uygulamak için istemci tarafında XSLT'yi kullanır. Bu, JavaScript ekosisteminden ayrı bir tembel şablon oluşturma dili olarak işlev görür.

Bu daha genel soruna iki çözüm vardır. Bu şekilde oluşturulmuş mevcut bir site için en kolay çözüm, mevcut işlevselliği korumak amacıyla yalnızca polyfill eklemektir. Alternatif olarak, XSLT dönüşümünü sunucu tarafında gerçekleştirebilir ve sonuçtaki HTML'yi ham XML yerine istemciye sunabilirsiniz. Bu tür özellikler için daha uzun vadeli çözüm, daha modern bir JavaScript veya JSON tabanlı çerçeveye geçmektir.

Bu XSLT desteğinin sonlandırılmasıyla ilgili olarak Chrome'da belirli bir sorunla karşılaşırsanız buradan hata bildirin.

XSLT kullanımı nasıl algılanır?

Genellikle, XSLT gibi kullanımdan kaldırılan özellikler kod tabanınızda birkaç şekilde tespit edilebilir. Bu bölümde bunlardan ikisi özetlenmektedir.

Reporting API

Reporting API, web uygulamalarının özelliklerin kullanımdan kaldırılması da dahil olmak üzere çeşitli platform özellikleri ve koşulları hakkında rapor oluşturmak için kullandığı genel bir raporlama mekanizmasıdır. XSLT desteğinin sonlandırılmasıyla ilgili rapor oluşturmak için aşağıdaki gibi bir kod snippet'i kullanılabilir:

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();

Bu kodun CodePen'deki işleyiş şeklini inceleyin.

Kurumsal eski teknoloji raporu

Bir işletmenin yöneticileri, kullanımdan kaldırılan özelliklerin kullanımını otomatik olarak toplamak ve bunları kullanıcı dostu bir şekilde bildirmek için Eski Teknoloji Raporu'nu kullanabilir. Bu özelliği etkinleştirme hakkında daha fazla bilgi için bu Google Destek Makalesi'ne bakın.