Bir web uygulamasında “küçük bir yorum alanı” ya da “masum bir arama kutusu” bazen en büyük güvenlik sorununa dönüşebiliyor. Bunu yıllar içinde defalarca gördüm. Özellikle yoğun geliştirme dönemlerinde ekipler hızlanmak isterken bir yerde “sonra temizleriz” dediği noktalar, XSS için kapı aralıyor. İşin kötü yanı şu: XSS çoğu zaman sessiz ilerler. Kullanıcı fark etmez, geliştirici fark etmez, ta ki bir gün veriler sızana ya da hesaplar ele geçirilene kadar.
Bu yazıda Cross-Site Scripting (XSS) Saldırıları ve Korunma Yöntemleri konusunu gerçekten anlaşılır bir dille ele alacağız. Web uygulamalarındaki XSS (Cross-Site Scripting) açıkları ve input validation ile sanitization rehberi arayanların tüm temel sorularını yanıtlayacağım. XSS nedir? türleri, çalışma mantığı ve yaygın saldırı senaryoları neler, web uygulamalarında input validation ve output sanitization ile XSS önleme teknikleri nasıl uygulanır, gerçek projelerde XSS güvenlik best practices ve yaygın hatalar nelerdir, JavaScript ve frameworklerde XSS’e karşı güvenli kod yazma yöntemleri nasıl olmalı… Hepsini sohbet gibi ama net bir şekilde konuşacağız. Sonunda da web güvenliği ve XSS eğitimi yakınımda diye düşünenlere pratik bir yol göstereceğim.
Hedef anahtar kelimeyi de yerli yerinde kullanacağım: Cross-Site Scripting (XSS) Saldırıları ve Korunma Yöntemleri. Çünkü bu başlık, hem teknik hem de pratik olarak konunun özünü taşıyor.
Cross-Site Scripting (XSS) Nedir?
XSS Tanımı
XSS, saldırganın bir web uygulaması üzerinden kullanıcıların tarayıcısında zararlı JavaScript çalıştırmasını sağlayan güvenlik açığıdır. Buradaki kritik ifade “kullanıcının tarayıcısında” kısmı. Yani saldırgan, senin sitenin güvenilirliğini kullanarak kullanıcı tarafında kod çalıştırır.
XSS Nasıl Çalışır?
XSS genelde şu zincirde ortaya çıkar: Uygulama bir kullanıcı girdisini alır, yeterince güvenli şekilde işlemez ve bunu sayfada tekrar kullanıcıya gösterir. Eğer bu gösterim doğru biçimde encode edilmezse, tarayıcı bu metni “metin” olarak değil “çalıştırılacak script” olarak yorumlayabilir.
Ben ekiplerle çalışırken XSS’i şu cümleyle özetliyorum: “Kullanıcının gönderdiği şeyi, tarayıcıya yanlış formatta geri verirsen tarayıcı bunu kod sanabilir.” Bu kadar.
Neden Tehlikelidir?
Çünkü XSS ile oturum bilgileri çalınabilir, kullanıcı adına işlem yapılabilir, sahte arayüzler gösterilebilir, form verileri sızdırılabilir. Bazı ekipler XSS’i “küçük açık” sanıyor. Oysa doğru hedefe denk gelirse sonuç çok büyük olabilir.
XSS’in Web Güvenliğindeki Yeri
XSS, web güvenliğinin temel konularından biridir. Özellikle OWASP listelerinde yıllardır önemli bir başlık olarak yer almasının nedeni, çok yaygın olması ve etkisinin yüksek olmasıdır. Cross-Site Scripting (XSS) Saldırıları ve Korunma Yöntemleri başlığını ciddiye almak, aslında web uygulamasının güvenlik temelini ciddiye almaktır.
XSS Saldırıları Nasıl Gerçekleşir?
Güvensiz Kullanıcı Girdileri
Yorum alanları, profil bilgileri, arama kutuları, destek talebi metinleri, hatta URL parametreleri. “Kullanıcıdan gelen her şey potansiyel risktir” yaklaşımı burada temel kuraldır. Saldırgan, normal kullanıcı gibi görünerek uygulamaya payload sokmaya çalışır.
Tarayıcıda Script Çalıştırma Mantığı
Tarayıcı HTML’yi parse ederken bazı içerikleri script olarak çalıştırabilir. Örneğin bir yerde beklenmedik bir <script> etiketi, event handler (onclick gibi) ya da tehlikeli bir URL şeması devreye girerse, tarayıcı bunu yürütür. Bu yüzden XSS, “tarayıcı davranışı” ile “uygulamanın güven sınırı”nın kesişimindedir.
Input–Output Zincirindeki Hatalar
Birçok ekip input validation’a odaklanır ama output encoding’i kaçırır. Oysa XSS için en kritik savunma çoğu zaman output encoding/escaping’dir. Çünkü saldırgan input’u farklı yollardan sokabilir, ama sen çıktıyı doğru encode edersen tarayıcı bunu metin olarak görür.
Client-side Güvenlik Açıkları
Modern uygulamalarda XSS sadece backend ile ilgili değil. SPA’larda DOM manipülasyonu, innerHTML gibi kullanım hataları, üçüncü parti script’ler ve yanlış yapılandırılmış CSP gibi konular client-side açıkları büyütür.
XSS Türleri
Stored (Persistent) XSS
Stored XSS, zararlı script’in kalıcı şekilde saklanıp daha sonra başka kullanıcılara servis edilmesiyle oluşur. Genelde veritabanı, cache ya da log benzeri kalıcı alanlar işin içine girer.
Veritabanı Üzerinden Kalıcı Scriptler
Örneğin bir kullanıcı profil açıklamasına zararlı içerik ekler. Uygulama bunu kaydeder. Profil sayfasını gören herkesin tarayıcısında bu içerik çalışabilir. Bu, en tehlikeli XSS türlerinden biridir çünkü “tek sefer payload, çok kişiye etki” gibi çalışır.
Reflected (Non-Persistent) XSS
Reflected XSS, payload’un sunucu tarafından hemen yanıt içinde geri yansıtılmasıyla oluşur. Genelde URL parametreleri ve form gönderimleri üzerinden görülür.
URL ve Form Tabanlı Saldırılar
Örneğin bir arama sayfası “Aradığınız: {query}” diye gösterir. Query encode edilmezse, saldırgan link içine payload koyup kullanıcıya tıklatabilir. Bu tür saldırılar phishing ile çok sık birleşir.
DOM-based XSS
DOM-based XSS, payload’un sunucu yanıtından değil, tarayıcıdaki JavaScript’in DOM’u yanlış kullanmasından kaynaklanır. Bu yüzden “backend temiz, sorun yok” düşüncesi burada yanlıştır.
JavaScript ve DOM Manipülasyonu
Özellikle innerHTML, document.write, insertAdjacentHTML gibi API’lerin yanlış kullanımı riskli. Ayrıca location.hash, querystring gibi kaynaklardan veri alıp DOM’a kontrolsüz basmak sık hatadır.
XSS Saldırı Senaryoları
Session ve Cookie Çalma
En klasik senaryo: XSS ile cookie okumaya çalışmak. Eğer cookie’de oturum bilgisi varsa ve HTTPOnly değilse risk büyür. Modern uygulamalarda token’ı localStorage’da tutmak gibi tercihler de saldırı etkisini artırabilir. Bu yüzden oturum yönetimi ve saklama stratejisi çok kritik.
Kullanıcı Adına İşlem Yapma
XSS ile kullanıcı adına istek atmak mümkün olabilir. Örneğin kullanıcı oturum açmışken arka planda istek göndermek, form göndermek, ayarları değiştirmek gibi. Burada CSRF ile birleşen senaryolar da görülebilir.
Keylogging ve Form Manipülasyonu
Sayfaya eklenen script, kullanıcı form doldururken tuş vuruşlarını yakalayabilir ya da form action’ını değiştirip veriyi başka yere gönderebilir. Bu senaryolar özellikle login sayfaları ve ödeme akışlarında çok tehlikelidir.
Phishing ve Sahte Arayüzler
Saldırgan, gerçek sayfanın üstüne sahte bir modal basıp kullanıcıdan şifre isteyebilir. Kullanıcı URL aynı olduğu için kandırılabilir. XSS’in en sinsi taraflarından biri budur: her şey “normal” görünür.
XSS’in Olası Sonuçları
Hesap Ele Geçirme
Token çalma, kullanıcı adına işlem, şifre reset akışına müdahale. Sonuç hesap ele geçirmeye kadar gidebilir.
Veri Gizliliğinin İhlali
Kullanıcıya ait kişisel veriler, mesajlar, adres bilgileri, hatta kurumsal sistemlerde daha kritik içerikler sızabilir. Bu, sadece teknik değil itibar krizidir.
Marka Güveni Kaybı
Bir güvenlik olayı yaşandığında kullanıcı “ben burada güvende miyim?” diye sorar. Güven kaybını geri kazanmak zordur. Hele bir de sosyal medyada yayılırsa etkisi büyür. Dark web ve sızıntı konusunu merak ediyorsan şu yazıya da göz atabilirsin: Dark web nedir internetin görünmeyen katmanları.
Hukuki ve Regülasyon Riskleri
Kişisel veri sızıntısı, regülasyonlara takılabilir. Kurumlar için yaptırımlar, raporlama zorunlulukları ve hukuki süreçler gündeme gelebilir.
XSS Saldırılarına Karşı Temel Korunma Yöntemleri
Output Encoding / Escaping
En temel ve en etkili yöntem: çıktıyı doğru encode etmek. HTML içinde gösterilecekse HTML escape, attribute içinde kullanılacaksa attribute escape, JavaScript string içinde kullanılacaksa JS escape gibi bağlama göre encoding gerekir. XSS savunmasının kalbi “context-aware encoding”dir.
Input Validation ve Sanitization
Input validation, beklenen formatı zorlar. Sanitization ise tehlikeli içerikleri temizlemeye çalışır. İkisi de önemlidir ama “sadece sanitization yaptım, tamam” demek risklidir. Çünkü sanitization karmaşık bir iştir. Ben genelde şunu öneririm: mümkünse allowlist yaklaşımı kullan. “Sadece şu karakterler/formatlar kabul” gibi.
Web uygulamalarında input validation ve output sanitization ile XSS önleme teknikleri arayanlar için en net mesaj şu: input’u doğrula ama output’u mutlaka encode et.
HTTPOnly ve Secure Cookie Kullanımı
HTTPOnly cookie, JavaScript’in cookie’ye erişmesini engeller. Bu, XSS etkisini azaltır. Secure cookie ise sadece HTTPS üzerinden gönderilmesini sağlar. Bunlar tek başına XSS’i engellemez ama hasarı düşürür.
JavaScript’te Güvenli DOM Kullanımı
DOM’a içerik basarken textContent gibi güvenli API’leri tercih etmek, innerHTML kullanımını sınırlamak, gerektiğinde güvenilir sanitization kütüphaneleri kullanmak önemlidir. Ayrıca üçüncü parti script’lere dikkat etmek gerekir.
Gelişmiş XSS Koruma Teknikleri
Content Security Policy (CSP)
CSP, tarayıcıya “hangi kaynaklardan script çalıştırılabilir?” gibi kurallar koyar. Doğru yapılandırılmış CSP, XSS’i çok zorlaştırır. Ama yanlış CSP de sahte bir güven hissi yaratır. Bu yüzden adım adım sıkılaştırmak iyi bir yaklaşımdır.
Trusted Types Kullanımı
Trusted Types, DOM XSS’e karşı modern bir savunma yaklaşımıdır. Tehlikeli DOM sink’lerine sadece “güvenilir” olarak işaretlenmiş içeriklerin gitmesine izin verir. Özellikle büyük frontend kod tabanlarında hataları azaltabilir.
SameSite Cookie Politikaları
SameSite daha çok CSRF ile ilişkilendirilse de, bazı XSS sonrası senaryolarda da etkili olabilir. En azından cookie’nin farklı site bağlamlarında nasıl taşınacağını kontrol edersin. Güvenlik her zaman katmanlı düşünülmeli.
Framework’lerin Built-in Koruma Mekanizmaları
Modern framework’ler varsayılan olarak escaping yapar. Bu büyük avantaj. Ama “her durumda” değil. Örneğin raw HTML basma özellikleri, template injection, yanlış kullanım gibi durumlar korumayı delip geçebilir. O yüzden framework kullanmak tek başına yeterli sayılmaz.
Frontend ve Backend Perspektifinden XSS
Frontend Framework’leri (React, Angular, Vue)
Bu framework’ler çoğu zaman output’u escape eder. Ancak “HTML’yi olduğu gibi bas” türü özellikler (örneğin bazı özel API’ler) çok risklidir. Ayrıca kullanıcı girdisini DOM’a elle basan custom kodlar, DOM-based XSS doğurabilir. JavaScript ve frameworklerde XSS’e karşı güvenli kod yazma yöntemleri denince ilk akla gelen şey: tehlikeli API’leri sınırlamak ve kod standardı koymaktır.
Backend Template Engine Güvenliği
Template engine’ler de genelde auto-escape sağlar ama her template aynı değildir. Bazı yerlerde “escape kapat” gibi kullanım yapılır. Bu tür kaçaklar, özellikle email template’leri, admin panelleri ve CMS ekranlarında büyük risk yaratır.
API ve JSON Response Güvenliği
“JSON güvenlidir” düşüncesi yanıltıcı olabilir. JSON’un kendisi script değildir ama frontend bunu yanlış yerde kullanırsa risk doğabilir. Örneğin JSON içindeki bir alan doğrudan innerHTML’ye basılırsa XSS olur. API ile UI arasındaki sınır net olmalı.
Client–Server Güven Sınırları
Sunucu, istemciye güvenmez. İstemci, sunucu yanıtını bağlama uygun şekilde işler. Bu sınır çizgisi net olmazsa, XSS gibi açıklar “iki tarafın arasında” büyür.
Yazılım Geliştirme Sürecinde XSS Önleme
Secure Coding Prensipleri
Trust no input. Yani hiç bir girdiye güvenme. Ayrıca “minimum yetki” yaklaşımıyla erişimleri sınırla. Kullanıcıya gösterdiğin her şeyin bağlama göre encode edilmesini standart hale getir.
Code Review ve Güvenlik Checklist’leri
Benim sevdiğim pratik: code review’da “DOM’a nerede basıyoruz?” sorusunu rutinleştirmek. Template’de escape kapatılmış mı, innerHTML var mı, kullanıcı girdisi nereden geliyor, güvenilir mi? Bu sorular checklist olursa XSS yakalama oranı yükselir.
Static ve Dynamic Security Testing
SAST araçları riskli pattern’leri yakalayabilir. DAST ise çalışan uygulamada açık taraması yapabilir. İkisini birlikte kullanmak daha iyi sonuç verir. Özellikle DOM XSS tarafında frontend odaklı taramalar faydalı olabilir.
DevSecOps ve CI/CD Entegrasyonu
Güvenliği sprint sonuna bırakmak yerine pipeline’a koymak gerekir. PR açıldığında lint ve SAST çalışsın, build aşamasında dependency taraması olsun, staging’de DAST tetiklensin. Bu yaklaşım “sonradan düzeltme” maliyetini ciddi düşürür.
Yaygın XSS Yanılgıları
“Sadece Backend Validation Yeterlidir” Algısı
Yeterli değil. Çünkü XSS çoğu zaman output bağlamında patlar. Backend validation kaçsa bile output encoding doğruysa risk azalır. Ayrıca DOM-based XSS tamamen client tarafında olabilir.
“Framework Kullanıyorum, XSS Olmaz” Yanlışı
Framework’ler yardımcı olur ama yanlış kullanım her şeyi bozar. Raw HTML basma, üçüncü parti içerik, kullanıcı girdisini tehlikeli sink’lere gönderme gibi durumlar XSS’e kapı açar.
Sadece Form Alanlarının Riskli Olduğu Düşüncesi
URL parametreleri, header’lar, cookie’ler, third-party callback’ler, hatta log’lar bile risk kaynağı olabilir. XSS yalnızca “form” meselesi değildir.
Yazılımcılar için XSS Güvenlik Farkındalığı
Junior Geliştiriciler için Temel Hatalar
En sık hatalar: innerHTML kullanımı, kullanıcı girdisini doğrudan template’e basmak, “şimdilik böyle kalsın” deyip sanitize işini ertelemek, token’ı localStorage’da tutup XSS etkisini büyütmek. Junior için en iyi öğrenme yöntemi, küçük bir örnekte XSS’in nasıl oluştuğunu görüp sonra encode ile nasıl kapandığını deneyimlemektir.
Senior Geliştiriciler için Mimari Yaklaşım
Senior tarafta iş kod satırından mimariye çıkar. Güven sınırlarını çizmek, CSP stratejisi belirlemek, token/cookie saklama yaklaşımını seçmek, third-party script politikasını koymak. Bu kararlar, uygulamanın XSS’e dayanıklılığını belirler.
Defense in Depth Stratejisi
XSS savunmasında tek bir duvar yetmez. Katmanlı savunma gerekir: validation, encoding, CSP, cookie politikaları, güvenli DOM, test ve izleme. Bu katmanlar birlikte çalışınca risk ciddi azalır.
Trust No Input
Kaynağı ne olursa olsun, tüm girdiler düşmanca kabul edilir. Kullanıcı, API, üçüncü parti servis, hatta admin panelinden gelen veri bile. Güvenlik burada başlar.
Least Privilege
Bir script çalışsa bile, erişebileceği alanları sınırlamak hasarı düşürür. Yetkileri minimumda tutmak, admin işlemlerini ayrı güvenlik katmanlarıyla korumak gibi.
Sonuç: XSS’e Karşı Proaktif Güvenlik
Kullanıcı Tarafı Güvenliğin Önemi
Web uygulamaları tarayıcıda yaşar. Bu yüzden kullanıcı tarafı güvenliği, “arkaya bırakılacak” bir konu değildir. Cross-Site Scripting (XSS) Saldırıları ve Korunma Yöntemleri dediğimiz şey, aslında kullanıcıyı koruma meselesidir.
Sürekli Test ve İzleme
Güvenlik bir kez yapılıp bırakılmaz. Yeni özellik gelir, yeni risk gelir. Log’lar, hata raporları, CSP raporlama, güvenlik taramaları ve düzenli kontrol kültürü şarttır.
Güvenli Web Uygulaması Kültürü
En kalıcı çözüm kültürdür. Ekip güvenli kod yazmayı standart haline getirirse, XSS gibi açıklar “şans eseri” değil “tasarımla” azalır. Bu yazıdaki tekniklerin hepsi, o kültürün bir parçasıdır.
Eğer web güvenliği ve XSS eğitimi yakınımda diye düşünüyorsan, uygulamalı örneklerle ilerlemek istersen Diyarbakır Yazılım Topluluğu sayfasına göz atabilirsin. Topluluğu daha yakından tanımak için hakkımızda bölümünü de inceleyebilirsin.
Son çağrı: Cross-Site Scripting (XSS) Saldırıları ve Korunma Yöntemleri konusunda ekibinle daha güvenli bir standart oluşturmak istiyorsan, bugün küçük bir adım at. Kod tabanında innerHTML ve benzeri riskli sink’leri tara. Template’lerde escape kapatılan yerleri listele. CSP’yi raporlama modunda aç. Bu üç adım bile seni ciddi ileri taşır. Diyarbakır Yazılım Topluluğu’nda bunları birlikte planlayabiliriz.
Sık Sorulan Sorular
Cross-Site Scripting (XSS) nedir ve nasıl çalışır?
XSS, saldırganın web uygulaması üzerinden kullanıcı tarayıcısında zararlı JavaScript çalıştırmasına imkân veren güvenlik açığıdır. Genelde kontrolsüz kullanıcı girdisinin sayfada yanlış biçimde gösterilmesi sonucu oluşur.
XSS saldırılarının türleri (stored, reflected, DOM-based) nelerdir?
Stored XSS, payload’un kalıcı şekilde saklanıp diğer kullanıcılara servis edilmesidir. Reflected XSS, payload’un istekte gelip yanıtta hemen yansıtılmasıdır. DOM-based XSS ise sunucudan bağımsız şekilde tarayıcıdaki JavaScript’in DOM’u yanlış kullanmasıyla ortaya çıkar.
XSS saldırıları web uygulamalarına ne gibi zararlar verir?
Oturum ve token hırsızlığı, kullanıcı adına işlem yapma, veri sızıntısı, phishing arayüzleri, marka güveni kaybı ve hukuki riskler XSS’in olası sonuçlarıdır.
XSS saldırılarına karşı hangi korunma ve güvenlik yöntemleri uygulanmalıdır?
Bağlama göre output encoding/escaping, güçlü input validation ve gerektiğinde sanitization, HTTPOnly/Secure cookie kullanımı, güvenli DOM API’leri, CSP, Trusted Types, SameSite politikaları, güvenlik testleri ve CI/CD içinde DevSecOps uygulamaları temel yöntemlerdir.
XSS güvenliği eğitimi veya siber güvenlik kursu yakınımda nerede bulunur?
Uygulamalı XSS örnekleriyle öğrenmek, güvenli kod standartları oluşturmak ve topluluk desteğiyle ilerlemek istiyorsan Diyarbakır Yazılım Topluluğu iyi bir başlangıç noktasıdır. Eğitim ve etkinlikler için hizmetler sayfasını takip edebilirsin.