Modern Web Uygulamalarında En Sık Görülen Güvenlik Açıkları

Web uygulamaları artık sadece kod parçaları değil; finans, sağlık, eğitim, sosyal medya gibi hayatın en kritik alanlarını taşıyan sistemler. Ama ne kadar gelişmiş olurlarsa olsunlar, saldırıların odağında olmaktan kurtulamıyorlar. 2025 güvenlik raporları hâlâ aynı gerçeği ortaya koyuyor:
👉 En büyük veri ihlalleri, aslında önceden bilinen ama önlem alınmayan açıklar yüzünden gerçekleşiyor. Bu yazımızda, modern web uygulamalarında en sık görülen açıkları yakından inceliyoruz.

 

SQL ve NoSQL Injection

Kullanıcı girdisinin doğrudan veritabanı sorgularına eklenmesi hâlâ saldırganların en güçlü silahlarından biri. Ancak günümüzde saldırılar yalnızca klasik SQL Injection ile sınırlı değil; NoSQL, ORM tabanlı sistemler ve API’ler üzerinden de veri çalmak mümkün.

Senaryo 1 - Klasik SQL Injection:
Bir e-ticaret sitesinde kullanıcı ürün arıyor. Normalde “telefon” yazması gerekirken, saldırgan şunu giriyor:

'; DROP TABLE kullanici;--

Eğer uygulama girdi doğrulaması yapmıyorsa, tüm kullanıcı tablosu silinebilir veya veri sızabilir.

• SQL tabanlı sistemlerde: Yanlış yazılmış bir WHERE sorgusu tüm tabloyu ifşa edebilir.
• Blind SQL Injection: Veri tabanının yanıtları doğrudan görünmese de, saldırgan mantıksal sorular ile bilgi çıkarabilir.

 

Senaryo 2 - NoSQL Injection:
MongoDB veya CouchDB gibi NoSQL sistemlerinde kullanıcı girdisi JSON formatında işlenir. Örnek:

{ "username": { "$ne": null }, "password": "sifre" }

Bu tarz manipülasyonlar ile saldırgan kimlik doğrulama kontrollerini bypass edebilir.

 

Senaryo 3 - ORM ve API Injection:
Modern uygulamalar ORM (Object-Relational Mapping) veya GraphQL/REST API kullanıyor. Eğer sorgular güvenli şekilde parametrize edilmemişse:

• ORM query’leri bypass edilebilir
• GraphQL’de nested query ve argument manipulation ile hassas verilere erişilebilir

Olası sonuçlar:

• Kullanıcı verilerinin sızması veya değiştirilmesi
• Sunucuda yetkisiz veri erişimi
• API üzerinden kritik işlevlerin kötüye kullanılması

 

💡 Mini ipucu:

1. Tüm kullanıcı girdilerini sanitize et ve parametrized query/ORM kullan.
2. ORM ve NoSQL sorgularında kullanıcı girdilerini doğrudan birleştirme.
3. API endpoint’lerinde yetki kontrollerini her sorguda tekrarla.
4. Blind injection’ı önlemek için hata mesajlarını minimuma indir ve logları güvenli tut.

 

XSS (Cross-Site Scripting)

XSS, bir saldırganın zararlı kodu web uygulamasına enjekte edip, bu kodun başka kullanıcıların tarayıcısında çalışmasını sağlamasıdır. Modern web’de XSS yalnızca klasik <script> enjeksiyonu ile sınırlı kalmaz; DOM tabanlı ve API tabanlı etkileşimlerde de ortaya çıkabilir.

Örneğin bir blog sitesinde yorum alanına şu kod girildiğinde:

<script>alert("Hacklendi!")</script>

her kullanıcı yorumu görüntülediğinde tarayıcı kodu çalıştırır. Benzer şekilde, kötü amaçlı bir link tıklanırsa (example.com/search?query=<script>alert('hack')</script>), sadece linki tıklayan kullanıcının tarayıcısında script çalışır.

DOM tabanlı XSS’te ise JavaScript ile alınan kullanıcı girdileri doğrudan sayfaya yerleştirilirse, saldırgan sayfa üzerinde kontrol sağlayabilir. Örneğin URL’den gelen parametreler doğrudan innerHTML ile ekleniyorsa, bu durum saldırıya açıktır.

Olası sonuçlar:

• Kullanıcı oturum bilgileri çalınabilir (cookie, localStorage)
• Phishing saldırıları veya sahte formlar aracılığıyla kimlik bilgileri elde edilebilir
• Kullanıcı fark etmeden başka sayfalara yönlendirilebilir veya zararlı script çalıştırılabilir
• Modern SPA’lerde (React, Angular, Vue) DOM XSS ile kullanıcı etkileşimi manipüle edilebilir

 

Mini ipuçları:

• Tüm kullanıcı girdilerini HTML encode et
• Güvenli kütüphaneler ve framework’lerin XSS koruma mekanizmalarını kullan
• DOM manipülasyonlarında innerHTML yerine textContent veya güvenli binding yöntemlerini tercih et
• CSP (Content Security Policy) ile hangi scriptlerin çalışabileceğini sınırla
• User input validation ve sanitization’ı backend ve frontend’de birlikte uygula

 

CSRF (Cross-Site Request Forgery)

CSRF, kullanıcı ile web uygulaması arasındaki güven ilişkisini hedef alan bir saldırıdır. Kullanıcı bir siteye giriş yaptıktan sonra, başka bir sitedeki zararlı kod onun adına işlem yapabilir.

Örnek senaryo: Siz bankanızda oturum açtınız ve hesabınızı kontrol ediyorsunuz. Aynı anda başka bir sekmede veya e-posta üzerinden zararlı bir linke tıkladınız. Bu link, sizin adınıza bankada para transferi, profil güncelleme veya başka kritik işlemler gönderebilir. Kullanıcı hiçbir şey fark etmez; tüm işlemler arka planda, oturumunuz kullanılarak gerçekleştirilir.

CSRF saldırıları genellikle:

• Kullanıcıların güvenli olmayan siteleri ziyaret etmesi,
• Oturum yönetiminin ve token kullanımının yetersiz olması,
• Form ve isteklerin doğrulama kontrollerinin eksik olması durumunda gerçekleşir.

Bu nedenle, CSRF’ye karşı her kritik işlem için token doğrulama, çift submit token, SameSite cookie ayarları gibi önlemler alınmalıdır. CSRF, “görünmez saldırı” olarak da adlandırılır çünkü kullanıcı fark etmeden gerçekleşir ve ciddi finansal ya da kişisel veri riskleri yaratabilir.

 

Güvensiz API Kullanımı

2025’in dünyasında çoğu uygulama API-first yaklaşımla geliştiriliyor. Ama API’ler güvenliksiz bırakıldığında:

• Kimlik doğrulama yapılmadan veri sızabilir,
• Rate limit olmaması durumunda brute-force saldırıları kolaylaşır,
• Yanlış CORS ayarları ile dışarıdan istenmeyen erişimler sağlanır.

Senaryo: Bir mobil uygulama, token doğrulaması olmadan kritik kullanıcı verilerini döndürüyor. Saldırgan bu API’yi kullanarak tüm kullanıcı verilerini indirebilir.

Mini ipucu: API’lerde mutlaka kimlik doğrulama, rate limiting ve doğru CORS politikası uygulayın.

 

Broken Authentication & Session Management

Eksik veya yanlış kimlik yönetimi, ciddi güvenlik açıklarına yol açar.

Saldırı örnekleri:

• Brute-force ile parola kırma (rate limiting yoksa kolay).
• Oturum tokenlerinin kolay tahmin edilmesi veya uzun süre geçerliliği.

 

Önlemler:

• Güçlü parola politikaları ve MFA zorunlu kılma,
• Oturum sürelerini uygun ayarla ve revocation mekanizması sağla,
• Tokenleri güvenli sakla (httpOnly, secure flags),
• Hesap kilitleme veya fail2ban benzeri önlemler.

Senaryo: Bir forum sitesinde 1000 kullanıcı var ve saldırgan otomatik script ile 10 saniyede 50 hesap denemesi yapabiliyor. Eğer rate limiting yoksa saldırgan kısa sürede hesapları ele geçirebilir.

 

 

Broken Access Control (Erişim Kontrolü Eksiklikleri)

Kullanıcıların kendi yetkilerinin ötesindeki kaynaklara erişebilmesi ciddi bir risk.

Senaryo: Bir kullanıcı kendi profilini görüntüleyebilirken id parametresini değiştirince başka bir kullanıcının verisine erişebiliyor.

Önlemler:

• Erişim kontrollerini server-side zorunlu kıl,
• Object-level authorization uygulayın,
• Privilege escalation yollarını düzenli test edin.

Mini ipucu: Her API isteğinde kullanıcı yetkisini tekrar doğrulamak, access control hatalarını azaltır.

 

Insecure Deserialization (Güvensiz Serileştirme)

Güvensiz serileştirme, saldırganın kod çalıştırmasına veya veri manipülasyonu yapmasına izin verir.

Örnek: Bir oyun uygulamasında skor verisi serialized olarak gönderiliyor. Saldırgan veriyi değiştirip yeniden gönderirse, oyunda kendi skorunu sonsuz yapabilir veya sistemde RCE oluşabilir.

Önlemler:

• Güvenilmeyen serialized datayı kabul etmeyin,
• Dijital imzalarla veri bütünlüğünü denetleyin,
• Kısıtlı sınıf listesi kullanın.

Mini ipucu: Mümkünse JSON veya güvenli veri formatları kullanın ve deserialize işlemini kısıtlayın.

 

Ransomware & Cryptojacking Riskleri

Web uygulamaları artık sadece veri depolamakla kalmıyor; aynı zamanda kullanıcı cihazları ve bulut altyapısını da etkileyebiliyor. Özellikle kötü amaçlı scriptler aracılığıyla cihazlara zarar verebilir veya işlemci kaynaklarını gizlice kullanabilir.

Senaryo: Bir e-ticaret sitesinde reklam alanına zararlı bir JavaScript eklenmiş. Ziyaret eden kullanıcıların tarayıcıları, fark etmeden kripto madenciliği yapmak için kullanılıyor (cryptojacking). Bazı zararlı payloadlar, kritik verileri şifreleyip kullanıcıdan fidye talep edebiliyor (ransomware).

• Kullanıcı cihazlarının yavaşlaması veya çökmesi
• Bulut veya sunucu kaynaklarının izinsiz kullanımı
• Fidye talepleri veya veri kaybı riski

💡 Mini ipucu: Tüm üçüncü parti scriptleri güvenlik taramasından geçir, CSP (Content Security Policy) ve Subresource Integrity (SRI) kullan, kullanıcı taraflı işlemleri izinsiz çalıştırılmasını engelle.

 

 

Supply Chain / 3rd Party Kütüphane Güvenlik Açıkları

Modern web uygulamaları artık yüzlerce açık kaynaklı kütüphane ve paket üzerine kuruluyor. Bu kütüphanelerdeki açıklar, uygulamanın kendisi ne kadar güvenli olursa olsun ciddi risk oluşturuyor.

Senaryo: Bir npm paketi, kritik bir güvenlik açığı içeriyor ve projenize eklenmiş. Saldırgan bu açığı kullanarak sunucuya kötü amaçlı kod enjekte edebilir veya kullanıcı verilerini çalabilir.

• Remote code execution (RCE)
• Veri sızıntısı veya manipülasyonu
• Arka kapı açılarak uzun süre fark edilmeyen saldırılar

 

Mini ipucu:

1. Dependency taraması (Snyk, Dependabot) kullan
2. Kullanılmayan paketleri kaldır
3. Güvenlik güncellemelerini otomatik veya düzenli uygula
4. Paketlerin kaynağını doğrula ve SHA hash kontrolü yap

 

API Abuse & Misuse (GraphQL ve REST Modern Saldırılar)

API-first tasarım ve GraphQL kullanımının artmasıyla birlikte, API’ler kötü niyetli kullanım ve veri sızıntıları için yeni hedefler haline geldi. Özellikle rate limit ve authorization eksiklikleri ciddi risk oluşturuyor.

Senaryo: Bir sosyal medya uygulaması GraphQL endpoint’i açmış. Kullanıcı sorguları ile veri sınırları kontrol edilmiyor. Saldırgan, “data batching” ve “nested queries” ile yüz binlerce kullanıcı bilgisine erişiyor.

 

Olası Sonuçlar:

• Tüm kullanıcı profillerine yetkisiz erişim
• Sunucu kaynaklarının aşırı kullanımı ve DoS benzeri etkiler
• Hassas verilerin ifşası

 

💡 Mini ipucu:

• API rate limiting ve throttling uygula
• Kullanıcı yetkilerini her sorguda doğrula
• GraphQL’de depth limit ve complexity limit kullan
• Sensitive veri endpoint’lerini logla ve anormal kullanımda uyarı üret

 

Yanlış Yapılandırmalar (Misconfiguration)

Bazen güvenlik açıklarının kaynağı kodda değil, sistem veya uygulama ayarlarında gizlidir. Yanlış yapılandırmalar, saldırganlara neredeyse kapıları otomatik açan fırsatlar sunar.

 

Örnekler:

• Açık bırakılan yönetici panelleri: Sisteme erişim kısıtlanmamış veya URL tahmin edilebiliyor.
• varsayılan parolalar (admin/admin, root/1234 vb.): Kullanıcı değiştirmeden bırakılan şifreler, saldırganların kolayca oturum açmasına imkan tanır.
• Güncellenmeyen sunucu yazılımları: Eski sürümler bilinen güvenlik açıklarıyla doludur ve güncelleme yapılmadığında saldırganlar bu açıklardan faydalanabilir.
• Yanlış yapılandırılmış API veya dosya izinleri: Kritik verilere gereksiz erişim verilebilir, güvenlik duvarı kuralları eksik olabilir.

Sonuç? Saldırgan hiçbir karmaşık saldırı yapmadan sisteme elini kolunu sallayarak girebilir. Bu yüzden güvenlik sadece yazılım geliştirme değil, aynı zamanda sistem yapılandırma ve yönetim disiplinidir.

 

💡 İpucu: Düzenli güvenlik denetimleri, güncellemeler ve varsayılan ayarların gözden geçirilmesi, bu tür açıkların önüne geçmek için kritik öneme sahiptir.

 

Ortak Nokta: Önlenebilirlik

Fark ettiniz mi? Bu açıkların çoğu önceden bilinen ve tamamen önlenebilir türden. Peki, 2025 yılında hâlâ neden sıkça karşımıza çıkıyorlar?

 

Başlıca sebepler:

• Hızlı Yayın Baskısı: Projeler piyasaya sürülürken güvenlik kontrolleri çoğu zaman ikinci plana atılıyor. Hızlı teslimat, çoğu zaman kritik güvenlik adımlarının atlanmasına yol açıyor.
• Güvenliğin Sonradan Eklenmesi: Yazılım geliştirme sürecinde güvenlik, “ekstra bir özellik” gibi düşünülüyor. Bu yaklaşım, güvenlik açıklarının üretim ortamına taşınmasına neden oluyor.
• Yetersiz Test Süreçleri: Otomatik testler veya manuel kontroller güvenlik açısından eksik kalabiliyor. Özellikle XSS, SQL Injection veya CSRF gibi saldırılar testlerde gözden kaçabiliyor.
• Eğitim ve Farkındalık Eksikliği: Geliştiricilerin güncel güvenlik önlemleri ve en iyi uygulamalar konusunda yeterince bilinçli olmaması, bilinen açıkların tekrar ortaya çıkmasına neden oluyor.
• Altyapı ve Konfigürasyon Problemleri: Sunucuların, API’lerin veya veritabanlarının yanlış yapılandırılması, kod güvenliği ne kadar iyi olursa olsun risk yaratıyor.

 

Özetle: Güvenlik açıkları karmaşık ve kaçınılmaz sorunlar değil; çoğu zaman proje yönetimi, süreç ve farkındalık eksikliğinden kaynaklanıyor. 2025’te bile aynı açıkların listelerde yer almasının nedeni işte bu.

 

Mini Görev

Bir web uygulaması hayal edin:

• Kullanıcı adı ve şifre ile giriş var,
• Bir yorum alanı mevcut,
• Arkada bir API çalışıyor.

Bu senaryoda hangi güvenlik açıkları ortaya çıkabilir?
Kendi not defterinize yazın ve “bu açığı nasıl engelleyebilirim?” diye düşünün.

 

💭 Unutmayın:
Güvenlik bir kere düşünülüp biten bir iş değildir.
Her satırda, her yapılandırmada ve her kullanıcı etkileşiminde yeniden ele alınması gerekir.

 

Bu Serinin İlk Durağı

Bu yazıda gördüğünüz açıklar sadece tehlikenin haritası. Yani “nerede risk var” sorusuna cevap. Ama “bu riskleri nasıl engelleriz?” sorusunun cevabı ayrı bir yolculuk.

Bir sonraki yazımızda ikinci adımı atacağız:
👉 Input Validation ve Sanitization Stratejileri ile, özellikle XSS ve Injection saldırılarını nasıl önleyebileceğimizi konuşacağız.