innerHTML ile XSS ve Bunu Önleme

el.innerHTML = userInput kullanmak, dizeyi HTML olarak ayrıştırır. userInput içinde <script> etiketleri veya olay işleyici öznitelikleri (onclick, onerror) varsa tarayıcı bunları yorumlar ve saldırganın denetimindeki kodu sayfada çalıştırır.

Kullanıcı verilerini HTML'e yerleştiren her kod — sunucu şablonları ve istemci tarafı oluşturma dâhil — veriler kaçırılmamışsa XSS riski taşır. API yanıtlarından innerHTML oluşturan tek sayfalı uygulamalar, bu yanıtlar kullanıcı içeriği içerdiğinde özellikle savunmasızdır.

"Bob<img src=x onerror=alert(1)>" kullanıcı adı div.innerHTML = `Welcome, ${user}` aracılığıyla ayarlandığında, img yüklenemezse alert(1) çalışır. Aynı yük, textContent aracılığıyla düz metin olarak kullanıldığında zararsızdır; tarayıcı etiketleri değil, yalnızca karakterleri görür.

textContent yalnızca metin ayarlar; HTML özel karakterleri etiket olarak değil, gerçek karakterler olarak görünür. Bu, zamanın %90'ında kullanmanız gereken araçtır. innerHTML'ye yalnızca gerçekten biçimlendirme oluşturmanız gerektiğinde, metin için değil, geçin.

Kullanıcı verileriyle öğeler oluşturmak için bunları createElement ve textContent ile oluşturun: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Sonuç, yapısal olarak innerHTML ile aynıdır; ancak tasarımı gereği XSS'e karşı güvenlidir.

Sunucu tarafından üretilen güvenilir HTML (kendi şablonunuzun çıktısı veya güvenilir bir düzenleyiciden gelen temizlenmiş zengin metin) için innerHTML uygundur. Güvenilmeyen kaynaklardan gelen verilere, temizleme uygulamadan asla doğrudan uygulamayın.

Kullanıcılar zengin metin gönderiyorsa (yorum düzenleyicisi veya Markdown oluşturma gibi), innerHTML'yi ayarlamadan önce temizleyin: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify, <b>, <em> ve <a> gibi güvenli biçimlendirmeyi korurken tehlikeli etiketleri ve öznitelikleri kaldırır.

el.insertAdjacentHTML("beforeend", html), HTML dizelerini ayrıştırır; innerHTML ile aynı XSS saldırı yüzeyine sahiptir. Aynı kurallar geçerlidir: kullanıcı verilerini doğrudan vermeyin; temizleyin veya DOM yöntemlerini kullanın. Aynı durum document.write için de geçerlidir; ancak bunu artık kimse kullanmamalıdır.

React, Vue, Svelte ve Angular, yerleştirilen metni varsayılan olarak kaçırır; {name} güvenlidir. Bu çerçeveler, aynı XSS riskini taşıyan kaçış yolları sunar (dangerouslySetInnerHTML React'te, v-html Vue'da); bunları temizleme işlemiyle birlikte ve ölçülü kullanın.

Öznitelik değerleri bile saldırı vektörü olabilir: <a href={url}> içinde url="javascript:alert(1)" bulunması, bağlantıya tıklandığında kodu çalıştırır. Kullanıcı girdisini href, src veya URL taşıyan diğer özniteliklere yerleştirmeden önce URL'leri şema bazında doğrulayın (yalnızca http:, https:, mailto: ve tel: şemalarına izin verin).

Güncel tarayıcılar Trusted Types desteği sunar: CSP'yi require-trusted-types-for 'script' ile yapılandırdığınızda innerHTML ham dizeleri reddeder ve yalnızca politika tarafından sarılmış değerleri kabul eder. Böylece XSS, disipline değil API'ye dayalı olarak olanaksız hâle gelir.

Tek bir katman yeterli değildir. Şunları birleştirin: sunucuda girdi doğrulama, oluşturma sırasında çıktının kaçışlanması, enjekte edilen betikleri engellemek için CSP, ham dizeleri reddetmek için Güvenilir Türler ve herhangi bir innerHTML kullanımı için güvenlik incelemesi. Katmanlı savunma, herhangi bir katmandaki hatadan sağ çıkar.

el.textContent = userInput XSS'ye karşı güvenliyken el.innerHTML = userInput neden tehlikelidir?

Kullanıcı girdisinde innerHTML, klasik XSS vektörüdür. Metin için textContent, yapı için createElement+textContent, zengin HTML gerektiğinde bir HTML arındırıcısı kullanın. Öznitelik değerleri için URL şemalarını doğrulayın. Kod incelemesinden kaçan hataları etkisizleştirmek için CSP ve Güvenilir Türler'i katmanlayın. Modern çerçeveler varsayılan olarak kaçışlama yapar; güvenli olmayan kaçış yollarını seyrek kullanın ve inceleyin.