React Uygulamalarında XSS: Güvenli Veri İşleme Rehberi
React projelerinde XSS: JSX kaçışlamasının koruduğu ve korumadığı yerler, dangerouslySetInnerHTML ve DOMPurify, URL tabanlı vektörler, CSP ve token saklama kararı.
React XSS'i çözdü mü?
Büyük ölçüde — ama tamamen değil. JSX, süslü parantezle bağlanan her değeri otomatik olarak kaçışlar (escape); bu, klasik XSS vektörlerinin çoğunu kapatır. Ancak React'in bilinçli olarak koruma dışında bıraktığı kapılar vardır ve modern React projelerindeki XSS bulguları neredeyse her zaman bu kapılardan girer. Bu yazı o kapıların haritasıdır.
React'te XSS nereden girer?
Vektör | Neden çalışır | Önlem |
|---|---|---|
dangerouslySetInnerHTML | Kaçışlamayı bilinçli olarak devre dışı bırakır | DOMPurify ile sanitizasyon; mümkünse hiç kullanmamak |
javascript: URL'leri | href/src'ye bağlanan kullanıcı verisi kod çalıştırabilir | URL şema doğrulaması (http/https izin listesi) |
Üçüncü taraf script'ler | Sayfaya eklenen her script tam yetkiyle çalışır | Minimum üçüncü taraf; CSP; bütünlük (SRI) |
npm bağımlılıkları | Paket ele geçirme doğrudan uygulama kodu olur | Kilit dosyası, tarama, sürüm disiplini |
Sunucu tarafı şablonlara sızan veri | SSR/hidrasyon sırasında ham HTML üretimi | SSR çıktısında da kaçışlama; şablon disiplini |
dangerouslySetInnerHTML: isim uyarının kendisi
CMS içeriği, zengin metin editörü çıktısı veya e-posta şablonu göstermek için ham HTML basmak gerektiğinde tek güvenli yol, HTML'i basmadan önce DOMPurify gibi kanıtlanmış bir kütüphaneyle temizlemektir. Temizliğin istemcide değil — ya da yalnızca istemcide değil — sunucuda da yapılması gerekir: API'niz ham HTML'i temizlenmemiş saklıyorsa, o veriyi tüketen her yeni istemci (mobil uygulama, farklı bir frontend) aynı riski yeniden üretir.
URL'ler: href de bir çalıştırma yüzeyidir
Kullanıcıdan gelen bir bağlantıyı <a href={url}> ile basmak, javascript: şemalı bir değerle kod çalıştırmaya dönüşebilir. React, javascript: URL'leri için uyarı üretir ama sorumluluk uygulamadadır: dış kaynaklı her URL, izin verilen şemalara (http, https, mailto gibi) karşı doğrulanmalı; doğrulanamayan değer hiç basılmamalıdır.
Tedarik zinciri: XSS artık npm'den de geliyor
Frontend'in en büyük saldırı yüzeylerinden biri bağımlılık ağacıdır ve bu risk teorik değildir: 2018'de event-stream paketine sızdırılan kötücül kod belirli bir kripto cüzdanını hedef aldı; 2021'de ua-parser-js ele geçirilerek zararlı sürümler yayımlandı; 2022'de colors.js/faker.js olayı, tek bir bakımcının binlerce projeyi kırabildiğini gösterdi. Önlem seti: kilit dosyasının (package-lock) sürüm kontrolünde olması, CI'da bağımlılık zafiyet taraması, otomatik güncelleme botlarının insan onaylı çalışması ve kurulum script'lerinin kısıtlanması.
CSP: ikinci savunma hattı
Content-Security-Policy, tüm önlemler aşılsa bile enjekte edilen script'in çalışmasını veya veri kaçırmasını engelleyebilen ikinci hattır. SPA'lar için pratik yol: inline script gereksinimini kaldırmak, script kaynaklarını kendi alan adlarınızla sınırlamak ve politikayı önce Report-Only modda çalıştırıp ihlal raporlarıyla sıkılaştırmaktır.
Token nerede saklanmalı: localStorage mı, çerez mi?
Bu karar XSS ile doğrudan ilişkilidir: localStorage'daki token, sayfada çalışan herhangi bir script tarafından okunabilir — yani tek bir XSS, oturumun tamamen çalınması demektir. httpOnly çerezdeki token JavaScript'ten okunamaz; XSS'in etkisini o oturumdaki isteklerle sınırlar, karşılığında CSRF korumasını (SameSite + token) gerektirir. Yüksek riskli uygulamalarda dengeli tercih: httpOnly + Secure + SameSite çerez ve kısa ömürlü erişim token'larıdır.
İş etkisi: frontend güveni ölçülebilir
XSS, kullanıcı oturumlarının çalınmasının ve sayfa içi kart kopyalama (web skimming) saldırılarının ana kapısıdır; e-ticarette bunun düzenleyici karşılığı da vardır — İngiliz veri otoritesinin British Airways'e kestiği 20 milyon sterlinlik ceza, bir web skimming vakasının sonucuydu. Kurumsal müşterilerin güvenlik anketlerinde frontend bağımlılık politikası ve CSP artık standart sorulardır; hazır cevabı olan tedarikçi değerlendirmeden hızlı geçer.
Sık sorulan sorular
JSX kullanıyorsam sanitizasyona gerek var mı?
Süslü parantezle bastığınız düz metinler için hayır — React kaçışlar. Ham HTML basıyorsanız (dangerouslySetInnerHTML) evet, her zaman.
DOMPurify yeterli mi?
HTML sanitizasyonu için sektör standardıdır ve doğru yapılandırıldığında güçlüdür; ancak URL doğrulama, CSP ve bağımlılık disiplini gibi diğer katmanların yerini almaz.
SSR (Next.js vb.) riski değiştirir mi?
Temel kurallar aynıdır; ek olarak sunucuda üretilen HTML'de ve hidrasyon verisinde kaçışlama disiplinine dikkat edilmelidir — özellikle ham JSON'ın script etiketi içine gömüldüğü desenlerde.
Inline event handler'lar (onClick) riskli mi?
JSX'te fonksiyon referansı olarak bağlanan handler'lar güvenlidir; risk, string olarak HTML'e gömülen işleyicilerde ve ham HTML basımındadır.
Frontend güvenlik kontrol listesi
dangerouslySetInnerHTML envanteri çıkarıldı; her kullanım DOMPurify'dan geçiyor
Dış kaynaklı URL'lerde şema izin listesi uygulanıyor
package-lock sürüm kontrolünde; CI'da bağımlılık taraması aktif
Üçüncü taraf script envanteri minimum; mümkünse SRI kullanımda
CSP tanımlı (önce Report-Only, sonra zorunlu)
Token saklama kararı belgelendi (httpOnly çerez + CSRF önlemleri tercih edilir)
Üretim derlemelerinde kaynak haritaları ve debug çıktıları kapalı
SSH Yazılım, React tabanlı uygulamalarda frontend güvenlik denetimi, CSP kurulumu ve bağımlılık güvenlik süreci tasarımı sunar. Frontend'inizin fotoğrafını çıkarmak için bize ulaşın.