Web Güvenliği Rehberi: XSS, CSRF ve SQL Injection Koruma Yolları

Modern Web Geliştirmede Güvenlik Neden Hayati Öneme Sahiptir?

Dijital dönüşümün ivme kazanmasıyla birlikte web uygulamaları, kurumların ve bireylerin kritik verilerini işleyen birincil temas noktaları haline gelmiştir. Finansal işlemlerden sağlık verilerine, e-ticaret platformlarından kurumsal yönetim panellerine kadar her sistem internete açık mimariler üzerinde çalışmaktadır. Ancak bu yaygınlık, web uygulamalarını siber saldırganların bir numaralı hedefi haline getirmektedir. Verizon Veri İhlali Raporu (DBIR) verilerine göre, web uygulamalarına yönelik saldırılar tüm kurumsal güvenlik ihlallerinin yüzde 40'ından fazlasını oluşturmaktadır. Bu durum, web güvenliğinin yalnızca geliştirme sürecinin sonundaki bir kontrol adımı değil, projenin ilk satırından itibaren ele alınması gereken temel bir mühendislik disiplini olduğunu kanıtlamaktadır.

Web uygulama güvenliği, OWASP (Open Web Application Security Project) tarafından yayınlanan standartlar ve tehdit modellemeleri doğrultusunda şekillenmektedir. Güvenlik açıklarının maliyeti yalnızca veri kaybı veya hizmet kesintisiyle sınırlı kalmamakta; KVKK, GDPR ve PCI-DSS gibi yasal düzenlemeler nedeniyle milyonlarca liralık idari para cezalarını ve telafisi zor itibar kayıplarını beraberinde getirmektedir. IBM Maliyet Raporu, bir veri ihlalinin küresel ortalama maliyetinin 4,45 milyon dolara ulaştığını göstermektedir. Bu nedenle modern yazılım geliştirme süreçlerinde güvenli kodlama pratiklerini benimsemek, geliştiricilerin en kritik sorumluluklarından biridir.

Savunma derinliği (Defense in Depth) ve Sıfır Güven (Zero Trust) yaklaşımları, günümüz web mimarilerinin temel taşlarını oluşturmaktadır. Tek bir güvenlik katmanına güvenmek yerine, istemci tarafından sunucuya, veritabanından ağ altyapısına kadar her noktada bağımsız doğrulama mekanizmaları kurulmalıdır. Geliştiricilerin "kullanıcıdan gelen hiçbir veriye güvenme" ilkesini benimsemesi; XSS, CSRF ve SQL Injection gibi klasik ancak halen en yıkıcı sonuçlara yol açan saldırı vektörlerine karşı en güçlü kalkanı oluşturmaktadır.

Web Güvenliğinde Temel Prensipler ve Tehdit Modeli

Güvenli bir web uygulaması inşa etmek için CIA üçlüsü olarak bilinen Gizlilik (Confidentiality), Bütünlük (Integrity) ve Erişilebilirlik (Availability) prensiplerine tam uyum sağlanmalıdır. Tehdit modelleme süreçlerinde, saldırganın sistemde nasıl ilerleyebileceği öngörülmeli ve potansiyel zafiyet noktaları proaktif olarak kapatılmalıdır.

• Girdi Doğrulama (Input Validation): İstemciden gelen tüm verilerin tip, uzunluk, format ve karakter seti bakımından katı kurallarla sunucu tarafında filtrelenmesi.
• En Az Yetki İlkesi (Least Privilege): Veritabanı kullanıcıları ve sistem servislerinin yalnızca görevlerini yerine getirebilecekleri minimum yetki seviyesinde çalıştırılması.
• Güvenli Varsayılanlar: Sistem konfigürasyonlarının ve güvenlik başlıklarının varsayılan olarak en kısıtlayıcı modda başlatılması.

SQL Injection (SQLi) Tehdidi ve Kapsamlı Savunma Stratejileri

SQL Injection (SQLi), saldırganın bir web uygulaması üzerinden veritabanı motoruna yetkisiz SQL komutları enjekte etmesine olanak tanıyan kritik bir güvenlik açığıdır. Uygulama, kullanıcı tarafından sağlanan girdileri doğrudan dinamik SQL sorgusu dizesine eklediğinde ve bu girdileri yeterince filtrelemediğinde ortaya çıkar. Veritabanında saklanan parolalar, kredi kartı bilgileri, kişisel kimlik verileri ve ticari sırlar bu açık nedeniyle tamamen deşifre olabilir. Dahası, gelişmiş saldırılarda xp_cmdshell gibi veritabanı yordamları kullanılarak sunucu düzeyinde komut çalıştırma (RCE) seviyesine kadar erişim sağlanabilir.

SQL Injection saldırıları temel olarak üç kategoriye ayrılmaktadır: In-band SQLi, Inferential (Blind) SQLi ve Out-of-band SQLi. In-band SQLi saldırılarında saldırgan, sorgu sonucunu ve veritabanı hatalarını doğrudan web sayfasında görüntüler (Örn: ' UNION SELECT null, username, password FROM users --). Kör (Blind) SQL Injection saldırılarında ise sayfa doğrudan veri döndürmez; saldırgan uygulamanın HTTP durum kodlarındaki yanıt sürelerini (Time-based: WAITFOR DELAY '0:0:5') veya Boolean mantıksal tepkilerini analiz ederek verileri karakter karakter çeker.

SQL Injection zafiyetlerinin temel kaynağı, veri ile kodun aynı akış içinde karıştırılmasıdır. Aşağıdaki PHP örneğinde görüldüğü gibi, doğrudan dize birleştirme yöntemiyle oluşturulan sorgular saldırıya tamamen açıktır:

$query = "SELECT * FROM kullanicilar WHERE email = '" . $_POST['email'] . "' AND sifre = '" . $_POST['sifre'] . "'";

Bu sorguya admin' OR '1'='1 girdisi gönderildiğinde, doğrulama mekanizması atlanarak tüm kullanıcı tablosuna erişim sağlanır. Bu felaketi önlemenin tek kesin ve endüstri standardı çözümü Parametreli Sorgular (Prepared Statements / Parameterized Queries) kullanmaktır. Parametreli sorgular, veritabanı motoruna SQL mantığı ile kullanıcı verisini birbirinden tamamen ayrıştırmasını bildirir; böylece kullanıcı girdisi hiçbir koşulda çalıştırılabilir kod olarak yorumlanmaz.

Modern Dillerde Parametreli Sorgu Uygulamaları

Güvenli veritabanı iletişimi için doğrudan SQL yazmak yerine PDO, ORM (Object-Relational Mapping) veya güçlü kütüphaneler tercih edilmelidir:

• PHP PDO Kullanımı: $stmt = $pdo->prepare('SELECT id, ad FROM uyeler WHERE email = :email'); $stmt->execute(['email' => $email]);
• Node.js (pg / mysql2): const res = await client.query('SELECT * FROM users WHERE id = $1', [userId]);
• Python (psycopg2 / SQLAlchemy): cursor.execute("SELECT * FROM products WHERE category = %s", (category_name,))

Veritabanı Katmanında En Az Yetki Prensibi

Parametreli sorguların yanı sıra veritabanı kullanıcısının yetkileri sınırlandırılmalıdır. Web uygulamasının veritabanı kullanıcısı asla sa, root veya DBA yetkilerine sahip olmamalıdır. Yalnızca gerekli tablolarda SELECT, INSERT, UPDATE ve DELETE yetkileri tanımlanmalı; DROP TABLE, ALTER veya dosya okuma/yazma gibi idari izinler kesinlikle kaldırılmalıdır.

Cross-Site Scripting (XSS) Açığı ve İstemci Tarafı Güvenliği

Siteler Arası Betik Çalıştırma (XSS), kötü niyetli JavaScript kodlarının güvenilir bir web sitesi üzerinden kurbanın tarayıcısına enjekte edilerek çalıştırılması prensibine dayanır. OWASP istatistiklerine göre web uygulamalarının yaklaşık yüzde 55'inde en az bir tür XSS zafiyeti bulunmaktadır. XSS saldırıları sonucunda kullanıcıların oturum çerezleri (Session Cookies) çalınabilir, kurban adına yetkisiz API istekleri gönderilebilir, tuş kaydediciler (Keylogger) yerleştirilebilir veya kullanıcı sahte bir giriş ekranına yönlendirilerek kimlik avı (phishing) gerçekleştirilebilir.

XSS açıkları üç ana grupta incelenmektedir: Stored (Kalıcı), Reflected (Yansıyan) ve DOM-based XSS. Stored XSS, saldırganın enjekte ettiği zararlı betiğin doğrudan veritabanına, yorum alanlarına veya profil bilgilerine kaydedilmesiyle oluşur; sayfayı ziyaret eden her kullanıcı otomatik olarak enfekte olur. Reflected XSS, genellikle arama çubukları veya URL parametreleri aracılığıyla gelir ve sunucu bu girdiyi doğrulamadan anında HTML çıktısına dahil ettiğinde tetiklenir. DOM-based XSS ise tamamen istemci tarafında gerçekleşir; sunucuya istek gitmeden tarayıcıdaki JavaScript kodunun location.hash, document.write veya element.innerHTML gibi güvenli olmayan alıcıları (sinks) çalıştırmasıyla vuku bulur.

XSS zafiyetinden korunmanın ilk adımı, Bağlama Duyarlı Çıktı Kodlama (Context-Aware Output Encoding) uygulamaktır. HTML gövdesine yazılan bir veri ile bir JavaScript değişkeni veya HTML özniteliği (attribute) içine yazılan verinin kodlama kuralları farklıdır. HTML bağlamında <, >, &, " ve ' karakterleri sırasıyla <, >, &, " ve ' formatına dönüştürülmelidir.

DOM manipülasyonlarında innerHTML veya outerHTML yerine daima güvenli alternatifler olan textContent veya innerText tercih edilmelidir. Zengin metin (Rich Text / Markdown) girişine izin verilen senaryolarda ise kontrolsüz HTML kabul edilmemeli; DOMPurify gibi endüstri standardı kütüphaneler ile beyaz liste (whitelist) tabanlı temizleme (sanitization) gerçekleştirilmelidir.

İçerik Güvenlik Politikası (Content Security Policy - CSP)

CSP, XSS saldırılarının etkisini minimize eden en güçlü HTTP güvenlik başlığıdır. CSP sayesinde tarayıcıya hangi kaynaklardan JavaScript, CSS veya görsel yüklenebileceği kesin kurallarla bildirilir:

• Örnek Güvenli CSP Başlığı: Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com; object-src 'none'; base-uri 'self';
• Inline Script Engelleme: CSP, HTML içine doğrudan yazılmış <script> etiketlerini ve satır içi olay işleyicilerini (onload, onclick) varsayılan olarak engelleyerek saldırganın enjekte ettiği betiklerin çalışmasını önler.
• Nonce ve Hash Tabanlı Doğrulama: Dinamik betikler için her HTTP yanıtında benzersiz bir nonce değeri üretilerek yalnızca bu anahtara sahip betiklerin çalışmasına izin verilir.

Oturum Çerezlerinin Korunması: HttpOnly ve Secure Bayrakları

XSS zafiyeti oluşsa dahi saldırganın oturum çerezlerini ele geçirmesini önlemek için çerezler doğru parametrelerle tanımlanmalıdır. Bir kimlik doğrulama çerezi oluşturulurken HttpOnly bayrağı aktif edilmelidir. Bu bayrak, document.cookie nesnesi üzerinden JavaScript ile çerez okunmasını tamamen engeller. Ek olarak Secure bayrağı eklenerek çerezin yalnızca şifreli HTTPS bağlantıları üzerinden iletilmesi garanti altına alınmalıdır.

Cross-Site Request Forgery (CSRF) ve Yetkisiz İşlem Engelleme

Siteler Arası İstek Sahteciliği (CSRF / XSRF), kullanıcının daha önceden oturum açtığı güvenilir bir web sitesine, kendi bilgisi ve rızası dışında yetkisiz istekler gönderilmesini sağlayan bir saldırı türüdür. CSRF saldırısında saldırgan, kullanıcının kimlik doğrulama çerezlerinin veya tarayıcı oturumunun arka planda otomatik olarak isteklerle birlikte iletilmesinden faydalanır. Bu saldırı genellikle parola değiştirme, para transferi, e-posta adresi güncelleme veya yönetici paneli üzerinden yetki yükseltme gibi kritik durum değiştirici (state-changing) işlemleri hedefler.

Bir CSRF senaryosunda, kurban bir bankacılık sitesinde oturum açmışken aynı tarayıcının başka bir sekmesinde saldırgan tarafından kontrol edilen zararlı bir web sitesini ziyaret eder. Bu zararlı sayfada gizli bir form bulunur: <form action="https://banka.com/transfer" method="POST"><input type="hidden" name="alici" value="saldirgan_hesap"><input type="hidden" name="tutar" value="10000"></form><script>document.forms[0].submit();</script>. Tarayıcı, hedef domaine istek yaparken kullanıcının aktif oturum çerezlerini otomatik olarak isteğe ekler. Eğer bankacılık uygulaması CSRF korumasına sahip değilse, bu isteği meşru kullanıcıdan gelmiş gibi işler ve para transferini tamamlar.

CSRF saldırılarını engellemenin en yaygın ve etkili yöntemi Anti-CSRF Token (Synchronizer Token Pattern) kullanmaktır. Bu yöntemde sunucu, her kullanıcı oturumu veya her form işlemi için tahmin edilmesi imkansız, rastgele ve kriptografik olarak güvenli bir belirteç (token) üretir. Bu token HTML formuna gizli bir alan (hidden input) olarak eklenir veya AJAX isteklerinde özel bir HTTP başlığında (Örn: X-CSRF-Token) sunucuya geri gönderilir. Sunucu, gelen isteği işlemeden önce bu token'ın oturumdaki değerle eşleşip eşleşmediğini kontrol eder. Saldırgan üçüncü taraf bir siteden bu token'ı okuyamadığı için sahte istekler sunucu tarafından reddedilir.

Modern web güvenliğinde bir diğer devrim niteliğindeki savunma hattı ise çerezlerdeki SameSite özniteliğidir. Bu öznitelik, çerezlerin siteler arası (cross-site) isteklerde tarayıcı tarafından otomatik olarak gönderilip gönderilmeyeceğini belirler. Üç farklı modda yapılandırılabilir:

SameSite Çerez Konfigürasyonu

• SameSite=Strict: Çerez, üçüncü taraf sitelerden gelen hiçbir istekte (bağlantı tıklamaları dahil) gönderilmez. En yüksek güvenlik seviyesidir.
• SameSite=Lax: Güvenli varsayılan değerdir. Yalnızca üst düzey gezinmelerde (kullanıcının harici bir linke tıklaması gibi güvenli GET isteklerinde) çerez gönderilir; POST veya iframe isteklerinde engellenir.
• SameSite=None: Çerezin siteler arası her istekte gönderilmesine izin verir; ancak mutlaka Secure bayrağı ile birlikte HTTPS üzerinden kullanılmalıdır.

Çift Gönderim Çerezleri (Double Submit Cookie) ve Özel Başlıklar

Durumsuz (Stateless) REST API veya SPA (Single Page Application) mimarilerinde sunucu tarafında oturum saklanmadığı durumlarda Çift Gönderim Çerezi yöntemi uygulanır. Rastgele üretilen token hem bir çerez olarak tarayıcıya yazılır hem de istemci tarafında okunarak özel bir HTTP başlığına (X-XSRF-TOKEN) eklenir. Sunucu, başlıktaki değer ile çerezdeki değerin eşleştiğini doğrular. Tarayıcıların Aynı Kaynak Politikası (Same-Origin Policy - SOP) gereği saldırganın sitesi kurbanın alan adına ait özel başlıkları oluşturamayacağı için sistem tam koruma altına alınmış olur.

Modern Güvenlik Başlıkları (HTTP Security Headers) ile Tarayıcı Katmanını Güçlendirme

Web uygulama güvenliği yalnızca sunucu tarafındaki kod kalitesiyle sınırlı değildir; istemci tarayıcılarının güvenlik yeteneklerini aktif olarak yönetmek şarttır. HTTP Güvenlik Başlıkları, sunucunun HTTP yanıtları aracılığıyla modern tarayıcılara sunduğu güvenlik direktifleridir. Bu başlıklar doğru yapılandırıldığında Clickjacking, MIME-sniffing, man-in-the-middle (MITM) ve veri sızıntısı gibi birçok saldırı vektörünü tamamen bertaraf eder.

Tüm üretim ortamı web uygulamalarında bulunması gereken kritik güvenlik başlıkları şunlardır:

• Strict-Transport-Security (HSTS): Tarayıcıya sitenin sonraki ziyaretlerde yalnızca güvenli HTTPS protokolü üzerinden açılması gerektiğini zorunlu kılar. Örnek: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. SSL Striping saldırılarını engeller.
• X-Frame-Options: Web sayfasının başka bir sitede <iframe> veya <frame> içinde gömülmesini kontrol eder. Clickjacking saldırılarına karşı DENY veya SAMEORIGIN olarak ayarlanmalıdır.
• X-Content-Type-Options: Tarayıcıların dosya içeriklerini tahmin etmeye (MIME-sniffing) çalışmasını engeller. nosniff değeri verilerek yüklenen bir metin dosyasının çalıştırılabilir bir betik gibi yorumlanması önlenir.
• Referrer-Policy: Sayfadan harici bir siteye yönlendirme yapılırken HTTP Referer başlığında hangi bilgilerin gönderileceğini belirler. strict-origin-when-cross-origin seçeneği veri sızıntılarını engellemek için idealdir.
• Permissions-Policy (Feature-Policy): Tarayıcının kamera, mikrofon, coğrafi konum ve ödeme API'leri gibi hassas donanım ve özelliklerine erişimini sınırlar: Permissions-Policy: camera=(), microphone=(), geolocation=().

Bu başlıkların eksiksiz tanımlanması, güvenlik tarayıcılarında (SecurityHeaders, Mozilla Observatory) uygulamanızın en yüksek puan olan A+ derecesini almasını sağlar. Nginx, Apache veya Cloudflare gibi ters vekil (Reverse Proxy) sunucularında bu başlıkları merkezi olarak tanımlamak, arka uç mimarisinden bağımsız genel bir güvenlik kalkanı oluşturur.

DevSecOps ve Güvenli Yazılım Geliştirme Yaşam Döngüsü (SSDLC)

Güvenli web geliştirme, reaktif bir süreç değil, yazılım yaşam döngüsünün her evresine entegre edilmiş proaktif bir yaklaşım olmalıdır. DevSecOps kültürü, güvenliğin CI/CD (Sürekli Entegrasyon / Sürekli Dağıtım) boru hatlarına doğrudan entegre edilmesini ve kod yazılırken güvenlik açıklarının tespit edilmesini hedefler. Güvenlik açıkları prodüksiyon ortamına taşınmadan önce geliştirme aşamasında tespit edildiğinde, düzeltme maliyeti yaklaşık 30 kat daha düşük olmaktadır.

Geliştirme süreçlerine dahil edilmesi gereken temel test ve denetim metodolojileri şunlardır:

Statik ve Dinamik Güvenlik Testleri (SAST & DAST)

Güvenlik testleri geliştirme boru hattının ayrılmaz bir parçası olarak otomatikleştirilmelidir:

• Statik Uygulama Güvenliği Testi (SAST): SonarQube, Semgrep veya Snyk gibi araçlarla kaynak kodun henüz derlenmeden veya çalıştırılmadan taranması; olası SQLi, XSS ve güvensiz fonksiyon kullanımlarının anında raporlanması.
• Dinamik Uygulama Güvenliği Testi (DAST): OWASP ZAP, Burp Suite Enterprise gibi araçlarla çalışan web uygulamasının dışarıdan bir saldırgan gözüyle taranması ve çalışma zamanı zafiyetlerinin belirlenmesi.
• Yazılım Bileşen Analizi (SCA): NPM, Maven, Pip veya Composer gibi paket yöneticileriyle projeye dahil edilen üçüncü taraf bağımlılıklardaki bilinen CVE açıklarının tespiti (Örn: npm audit, Trivy).

Girdi Doğrulama ve Beyaz Liste (Allow-list) Yaklaşımı

Tüm kullanıcı girdileri sıkı bir doğrulama katmanından geçirilmelidir. Kara liste (Black-list) yöntemiyle zararlı karakterleri ayıklamaya çalışmak saldırganların atlatma (bypass) teknikleri karşısında genellikle başarısız olur. Bunun yerine, yalnızca izin verilen karakterlerin, formatların ve uzunlukların tanımlandığı Beyaz Liste (Allow-list / Positive Validation) yaklaşımı benimsenmelidir. E-posta, telefon, tarih veya tamsayı gibi alanlar düzenli ifadeler (Regex) ve tip güvenli şemalar (Zod, Joi, FluentValidation) ile doğrulanmalıdır.

Sonuç olarak; SQL Injection, XSS ve CSRF gibi güvenlik açıkları, modern web geliştiricilerinin karşısına çıkan en kritik tehditlerdir. Parametreli sorgular kullanmak, bağlama duyarlı çıktı kodlama yapmak, CSP ve HSTS gibi modern güvenlik başlıklarını etkinleştirmek, SameSite çerezlerini ve Anti-CSRF tokenlarını devreye sokmak web uygulamanızı aşılmaz bir kaleye dönüştürür. Güvenliği bir özellik değil, bir kalite metriği olarak ele almak hem kullanıcılarınızın verilerini hem de kurumunuzun dijital varlığını güvence altına alacaktır.