İçeriğe atla
Bilgi Merkezi/Makale
Makale

XSS (Cross-Site Scripting) Nedir? Türleri ve Korunma

XSS'in nasıl işlediğini, reflected, stored ve DOM tabanlı türlerini, CSRF'ten farkını ve çıktı kodlama, CSP ve çerez ayarlarıyla korunmayı anlattık.

Oğuzhan Gerçek··7 dk okuma
XSS (Cross-Site Scripting) Nedir? Türleri ve Korunma

Kısa cevap: XSS (Cross-Site Scripting, siteler arası betik çalıştırma), saldırganın bir siteye yerleştirdiği zararlı betiğin başka kullanıcıların tarayıcısında sitenin kendi kodu gibi çalıştığı bir injection açığıdır. Uygulama kullanıcıdan gelen veriyi etkisizleştirmeden sayfaya koyduğunda oluşur; üç türü var: reflected, stored ve DOM tabanlı. Saldırgan oturumu ele geçirebilir, kullanıcı adına istek gönderebilir ya da sayfayı değiştirebilir. Asıl korunma çıktıyı bağlamına göre kodlamaktır; Content Security Policy (CSP) ve HttpOnly çerez ikinci savunma hattını kurar.

XSS nedir?

OWASP'ın tanımıyla XSS, zararsız ve güvenilir web sitelerine kötü niyetli betiklerin enjekte edildiği bir injection türüdür. MITRE'nin CWE-79 kaydında tarif edilen zayıflıkta yazılım, kullanıcının kontrol ettiği girdiyi başka kullanıcılara sunulan bir web sayfasına koymadan önce etkisizleştirmez ya da yanlış etkisizleştirir.

Veri uygulamaya güvenilmeyen bir kaynaktan, çoğunlukla bir web isteğiyle girer ve doğrulanmadan kullanıcıya giden içeriğe eklenir. Tarayıcı bu yolla gelen betiğe güvenmemesi gerektiğini bilemez, onu çalıştırır; MDN'e göre kod artık sitenin kendi kodunun yapabildiği her şeyi yapabilir. SQL injection ile aynı aileden bir açık bu: orada girdi veritabanı sorgusuna, burada tarayıcının yorumladığı sayfaya karışır.

XSS türleri: reflected, stored ve DOM tabanlı

  • Reflected XSS: Betik, hata mesajı ya da arama sonucu gibi bir sunucu cevabıyla geri yansır. Kurban e-postadaki ya da başka bir sitedeki bağlantıya tıklamaya kandırılır; CWE'ye göre bu tür adresler birçok oltalama düzeneğinin çekirdeğidir.
  • Stored XSS: Betik veritabanı, forum ya da yorum alanı gibi bir yerde kalıcı olarak saklanır; kurban o bilgiyi istediğinde betiği de alır. OWASP'ın test rehberi bu türü en tehlikelisi sayıyor: kötü niyetli bir bağlantıya gerek kalmaz, sayfayı bir yönetici açarsa saldırı onun tarayıcısında çalışır.
  • DOM tabanlı XSS: OWASP'a göre saldırı, kurbanın tarayıcısındaki DOM değiştirildiği için çalışır; sunucunun cevabı aynı kalır. Saldırı girdisi adresin # işaretinden sonraki kısmındaysa sunucuya hiç ulaşmaz.

XSS saldırısı ne yapabilir?

OWASP'a göre en ağır XSS saldırıları oturum çerezini açığa çıkarır; saldırgan oturumu ele geçirip hesabı devralır. Diğer sonuçlar şunlar:

  • Kullanıcı adına işlem: MDN'e göre kod, kullanıcının kimlik bilgileriyle HTTP isteği gönderip onun kılığına girebilir; sitenin API'leri bu çağrıyı kullanıcıdan gelmiş sayar.
  • Sahte form: CWE'ye göre XSS, güvenilir siteyi taklit edip kurbana parolasını girdiren oltalama saldırılarında kullanılabilir.
  • Sayfayı değiştirme: Betik sayfanın içeriğini yeniden yazabilir, kullanıcıyı başka bir siteye yönlendirebilir ya da Truva atı türü zararlı yazılım kurdurabilir.

XSS ne kadar yaygın?

CWE programının 11 Aralık 2025'te duyurduğu 2025 CWE Top 25 listesinde CWE-79 birinci sırada. Duyuruya göre liste, 1 Haziran 2024 ile 1 Haziran 2025 arasında yayımlanan 39.080 CVE kaydına dayanıyor. Aynı listede CSRF (CWE-352) üçüncü. OWASP Top 10:2025 XSS'i A05:2025 Injection kategorisine koyuyor ve 30.000'i aşkın CVE kaydıyla sık görülen bir zayıflık olarak anıyor. CISA ile FBI'ın Eylül 2024 tarihli Secure by Design Alert belgesine göre ise XSS açıkları önlenebilir ve yazılım ürünlerinde hiç bulunmamalı.

XSS nasıl önlenir?

OWASP'ın XSS önleme rehberine göre XSS'i tek bir teknik çözmez; savunmaların birleşimi gerekir:

  1. Bağlama göre çıktı kodlama: Veri, düştüğü bağlama göre (HTML gövdesi, öznitelik, JavaScript, CSS ya da URL) kodlanarak sayfaya konur. CWE'ye göre doğru çıktı kodlama, kaçış ve tırnaklama XSS'e karşı en etkili çözüm. OWASP değişkenlerin eval gibi güvensiz işlevlere hiç konmamasını istiyor; orada kodlama da yetmez.
  2. Çerçevenin otomatik kaçışını delmemek: Modern çerçeveler şablon ve otomatik kaçışla (auto-escaping) XSS hatasını azaltır. Açık bu korumayı kapatan yollardan da girebilir: React'in dangerouslySetInnerHTML özelliği, Angular'ın bypassSecurityTrust işlevleri, şablon enjeksiyonu (template injection) ve eski sürüm eklentiler. React belgesine göre işaretleme tamamen güvenilir değilse bu yolla XSS açığı yaratmak çok kolay.
  3. HTML temizleme: Kullanıcı biçimli içerik (HTML) yazıyorsa kodlama XSS'i önler ama biçimi de bozar; OWASP bu durumda DOMPurify gibi bir temizleme (sanitization) kütüphanesi öneriyor. Temizlenen içerik sonradan değiştirilirse koruma boşa çıkabilir.
  4. Güvenli API ve girdi doğrulama: OWASP'a göre tarayıcıda çalışan kodda en güçlü savunma, innerHTML yerine textContent gibi güvenli JavaScript API'leridir. CISA ve FBI girdinin yapı ve anlam açısından doğrulanmasını istiyor; CWE'ye göre ise izin listesiyle (allowlist) doğrulama yalnızca bir ölçüde derinlemesine savunma sağlar.

Content Security Policy (CSP) ile ikinci savunma hattı

W3C'nin CSP Level 3 taslağına göre CSP, geliştiricinin bir sayfanın hangi kaynakları yükleyip çalıştırabileceğini denetlediği mekanizmadır; MDN'e göre asıl kullanım alanı XSS'e karşı savunma. Önerilen yöntem, nonce ya da hash tabanlı strict CSP: sunucu her HTTP cevabı için tahmin edilemeyen yeni bir nonce üretir, bu değeri hem politikaya hem meşru betik etiketlerine yazar; değerler eşleşmezse tarayıcı betiği yüklemez. 'unsafe-inline' anahtar kelimesi CSP'nin amacının büyük kısmını boşa çıkarır. Aşağıdaki örnek MDN'deki nonce tabanlı politikaya clickjacking'i engelleyen ve ihlal raporu isteyen iki yönerge ekliyor (okunurluk için satırlara bölündü):

Content-Security-Policy:
  script-src 'nonce-{RANDOM}';
  object-src 'none';
  base-uri 'none';
  frame-ancestors 'none';
  report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

Politika önce Content-Security-Policy-Report-Only başlığıyla denenebilir: tarayıcı politikayı uygulamaz, yalnızca ihlalleri raporlar. W3C'ye göre CSP ilk savunma hattı değil, derinlemesine savunmanın parçasıdır. W3C'nin onaylı standardı (Recommendation) 15 Aralık 2016 tarihli CSP Level 2; Level 3 Ekim 2026 itibarıyla taslak (Working Draft) aşamasında.

HttpOnly, SameSite ve Trusted Types

  • HttpOnly: MDN'e göre JavaScript'in çereze erişmesini yasaklar ve XSS'in etkisini azaltır. Ama çerez, betiğin başlattığı isteklerle yine gönderilir: betik oturum çerezini okuyamaz, kullanıcı adına istek yapabilir. OWASP'a göre çerez öznitelikleri açığın kök nedenini gidermez.
  • SameSite: Çerezin siteler arası isteklerle gidip gitmeyeceğini Strict, Lax ya da None değeriyle belirler; MDN'e göre CSRF'e karşı bir ölçüde koruma sağlar.
  • Trusted Types: MDN'in tanımıyla bu API, girdinin innerHTML gibi onu çalıştırabilecek bir API'ye verilmeden önce geliştiricinin tanımladığı bir dönüştürme işlevinden geçmesini güvenceye alır. CSP'deki require-trusted-types-for yönergesi bu API'lere düz metin verilmesini engeller. Temizleme işini API değil, geliştiricinin yazdığı politika yapar. MDN'e göre özellik Şubat 2026'dan beri başlıca tarayıcıların son sürümlerinde çalışıyor.

XSS ile CSRF arasındaki fark

OWASP'ın tanımıyla CSRF (Cross-Site Request Forgery, siteler arası istek sahteciliği), kullanıcıyı oturum açtığı bir web uygulamasında istemediği işlemleri yapmaya zorlayan saldırıdır. Durum değiştiren istekleri hedefler, çünkü cevabı saldırgan değil kurban alır. XSS'te ise saldırganın kodu sitenin içinde çalışır ve sayfaya erişir; OWASP'ın CSRF önleme rehberi bu yüzden XSS'in bütün CSRF önlemlerini aşabileceğini hatırlatıyor. Rehber CSRF'e karşı çerçevenin yerleşik korumasını ve synchronizer token desenini öneriyor; SameSite'ı ise yalnızca ek katman sayıyor.

XSS nasıl tespit edilir?

  • Kod incelemesi ve SAST: CISA ve FBI kod incelemesini ve saldırgan gözüyle sıkı ürün testlerini öneriyor. OWASP'a göre statik analiz (SAST) araçları sürekli entegrasyonda çalışabilir, ama yanlış alarmları çoktur (CI/CD yazımız).
  • DAST ve sızma testi: DAST araçları uygulamayı çoğunlukla dışarıdan tarar. OWASP'ın test rehberine göre otomatik testlerin DOM tabanlı XSS'teki başarısı çok sınırlı; istemci kodu elle incelenmeli. Taramayı zafiyet taraması sayfamızda, elle testi sızma testi yazımızda anlattık.
  • WAF: OWASP'a göre WAF'lar XSS'i önlemekte güvenilir değil: atlatılabiliyor ve yalnızca tarayıcıda çalışan XSS'i göremiyor. Kalıcı düzeltme gelene kadar sanal yama işlevi görebilir (WAF yazımız).

Uygulama katmanının korunmasını uygulama güvenliği (WAF), kapsamlı değerlendirmeyi güvenlik değerlendirmesi hizmetimizde ele alıyoruz.

Sık sorulan sorular

XSS ne demek? Cross-Site Scripting'in kısaltması; Türkçeye siteler arası betik çalıştırma diye çevrilebilir. Bir siteye yerleştirilen zararlı betiğin başka kullanıcıların tarayıcısında çalışmasıdır.

XSS açığı nasıl oluşur? Uygulama, güvenilmeyen bir kaynaktan gelen veriyi kodlamadan ya da temizlemeden sayfaya koyduğunda oluşur.

CSRF nedir, XSS'ten farkı ne? CSRF, oturum açmış kullanıcıya istemediği bir işlemi yaptırır ama saldırgan cevabı göremez. XSS'te kod sitenin içinde çalışır ve CSRF önlemlerini de aşabilir.

Content Security Policy (CSP) nedir? Sitenin, hangi betiklerin çalışabileceğini tarayıcıya bir HTTP başlığıyla bildirdiği güvenlik mekanizmasıdır. Çıktı kodlamanın yerine geçmez.

WAF XSS saldırısını önler mi? Tek başına önlemez. OWASP'a göre WAF'lar atlatılabiliyor ve DOM tabanlı XSS'i göremiyor; kalıcı çözüm kodun düzeltilmesidir.

Kaynaklar