Bu sayfa, Cloud Translation API ile çevrilmiştir.

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

Mason Freed

Dominik Röttsches

Yayınlanma tarihi: 29 Ekim 2025

Chrome, XSLT'yi tarayıcıdan kaldırmayı ve desteğini sonlandı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 XML stil sayfası işleme talimatı dahil olmak üzere XSLT'nin desteğini resmen sonlandırdı. 155 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, XSLT'nin kaldırılmasıyla ilgili geçmiş ve bağlam bilgileri 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.

Neler kaldırılıyor?

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

XSLTProcessor sınıfı (örneğin, new XSLTProcessor()).
XSLT İşleme Talimatı (örneğin, <?xml-stylesheet … ?>).

Timeline For Chrome

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 148 (10 Mart 2026 Canary): Canary, Dev ve Beta sürümlerinde, erken uyarı olarak XSLT varsayılan olarak devre dışı bırakılmaya başlanır.
Chrome 152 (25 Ağustos 2026): Kaynak denemesi (OT) ve Enterprise politikası (EP) test için kullanıma sunulur. Bu izinler, sitelerin ve işletmelerin özellikleri kaldırılma tarihinden sonra da kullanmaya devam etmesine olanak tanır.
Chrome 155 (17 Kasım 2026): XSLT, kararlı sürümlerde çalışmayı durdurur. Bu durum, kaynak denemesi ve kurumsal politika katılımcıları dışındaki tüm kullanıcılar için geçerlidir.**
Chrome 164 (17 Ağustos 2027): Kaynak denemesi ve kurumsal politika çalışmayı durdurur. 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ı, bu stil sayfasındaki kuralları kullanarak ham XML verilerini yeniden düzenler, biçimlendirir ve kullanıcı için oluşturulabilecek yapılandırılmış bir sayfaya (genellikle HTML) dönüştürür.

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

XSLT, 16 Kasım 1999'da World Wide Web Consortium (W3C) tarafından 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. Resmi 1.0 önerisinden önce Microsoft, Mart 1999'da yayınlanan Internet Explorer 5.0'da W3C çalışma taslağına dayalı tescilli bir uygulama göndererek erken bir girişimde bulundu. 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'ın 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'daki orijinal XSLT 1.0 için yerel destek sağlamaktadır. Bu gelişme eksikliği, JSON'un kablo biçimi olarak kullanımının artması ve daha esnek ve güçlü DOM manipülasyonu ve şablon oluşturma sunan JavaScript kitaplıkları ve çerçeveleri (ör. jQuery, React ve Vue.js) ile birleşince istemci tarafı XSLT kullanımında önemli bir düşüş yaşandı. Web tarayıcısındaki rolü büyük ölçüde bu JavaScript tabanlı teknolojilerle değiştirilmiştir.

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. libxslt (Chromium tarayıcılar tarafından kullanılır) gibi bu dönüşümleri işleyen temel kitaplıklar, karmaşık ve eski C/C++ kod tabanlarıdır. Bu tür kodlar, arabellek taşmaları gibi bellek güvenliği açıklarına karşı oldukça hassastır ve rastgele kod yürütülmesine yol açabilir. Örneğin, güvenlik denetimleri ve hata izleyiciler bu ayrıştırıcılarda tekrar tekrar yüksek önem derecesine sahip güvenlik açıkları tespit etmiştir (ör. CVE-2025-7425 ve CVE-2022-22834 (her ikisi de libxslt'de). İstemci tarafı XSLT artık nadiren kullanılan bir özellik olduğundan bu kitaplıklar, temel JavaScript motorlarına kıyasla çok daha az bakım ve güvenlik incelemesi alıyor. Ancak bu kitaplıklar, güvenilmeyen web içeriklerinin işlenmesi için doğrudan ve güçlü bir saldırı yüzeyini temsil ediyor. Aslında XSLT, tarayıcı kullanıcılarını risk altında bırakmaya devam eden son zamanlardaki çeşitli yüksek profilli güvenlik açıklarının kaynağıdır. Bu kırılgan ve eski işlevin sürdürülmesinin 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ştirilmekte, JavaScript motorlarına yapılan büyük güvenlik yatırımından faydalanmakta ve günümüzde neredeyse tüm web geliştiricileri tarafından kullanılmaktadır. Gerçekten de günümüzde web sayfası yüklemelerinin yalnızca yaklaşık %0, 02'sinde XSLT kullanılmakta olup %0, 001'den daha azında XSLT işleme talimatları kullanılmaktadı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 nedenlerle, XSLT'nin desteğinin sonlandırılması ve kaldırılması, tüm kullanıcılar için tarayıcının saldırı yüzeyini 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, Chromium'da XML'nin ayrıştırılması, serileştirilmesi ve iyi biçimlendirilmişliğinin test edilmesi için kullanılan libxml2'ye karşı 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ış, belleğe güvenli bir XML ayrıştırma kitaplığıyla değiştirmeyi planlıyoruz. Önemli olarak, tarayıcıdan XML'yi kaldırmayacağız. Burada 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.

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 işlem hattını 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 tarafı oluşturma gerçekleştirme yer alır.

JavaScript'te istemci tarafı XSLT

İstemci tarafında (JavaScript tabanlı) birkaç XSLT kitaplığı mevcuttur ancak en büyüğü Saxonica tarafından üretilir (Saxonica'ya ilişkin kapsamlı dokümanları 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 tek 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 belge türünü ve XSLT işleme talimatını algılayan ve belgeyi 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, XSLT, doğrudan bir tarayıcıda görüntülendiğinde ham XML feed'lerini okunabilir hale getirmek için kullanılır. Bir 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ı, bu özelliğin temel kullanım alanıdır.

Bu kullanım alanında iki olası yol 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 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](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 bunu okunabilir bir HTML biçimine dönüştüren tek bir XML veri feed'i oluşturarak bu işlemi yapar. Bu sayede API, cihazda veya tarayıcıda ek kod gerekmeden 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 semantik 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.