Web güvenliği artık yalnız firewall kurmak, SSL sertifikası kullanmak veya yılda bir kez pentest yaptırmakla yönetilemez. Modern web uygulamaları cloud, API, SaaS, CI/CD, üçüncü taraf JavaScript ve uzaktan çalışan ekiplerle genişleyen bir saldırı yüzeyine sahip.
2026 web güvenliği yaklaşımı; Zero Trust prensiplerini, browser güvenlik politikalarını, sürekli açık yönetimini ve yazılım geliştirme yaşam döngüsünü aynı kontrol sistemi içinde değerlendirmeyi gerektiriyor.
Zero Trust Nedir?
Zero Trust, belirli bir ağ içinde bulunan kullanıcı veya cihazı otomatik olarak güvenilir kabul etmemeyi esas alan mimari yaklaşımdır.
NIST’in Zero Trust Architecture çerçevesinin temel mantığı, erişimin kullanıcı, cihaz, kaynak ve bağlam temelinde sürekli değerlendirilmesidir.
NIST SP 1800-35 uygulama rehberi de farklı ürün ve mimarilerle çok sayıda örnek Zero Trust implementasyonu sunmaktadır.
Zero Trust Bir Ürün Değildir
Tek bir güvenlik ürünü satın alarak Zero Trust’a geçilmiş olmaz.
Mimari genellikle şu katmanları içerir:
- kimlik doğrulama,
- cihaz güveni,
- en az yetki,
- kaynak bazlı erişim,
- loglama,
- policy enforcement.
MFA Temel Kontrol Olmalı
Özellikle yönetici paneli, cloud hesabı, kod deposu, domain registrar ve kurumsal e-posta hesaplarında çok faktörlü kimlik doğrulama temel güvenlik katmanlarından biridir.
Ancak MFA tek başına yeterli değildir. Yetkilendirme ve session güvenliği de ayrıca yönetilmelidir.
Content Security Policy (CSP)
CSP, tarayıcıya hangi kaynaklardan script, style, font, frame ve diğer içeriklerin yüklenebileceğini bildiren güvenlik politikasıdır.
Doğru uygulandığında XSS gibi bazı saldırıların etkisini azaltmaya yardımcı olabilir.
Ancak geniş kapsamlı unsafe-inline veya unsafe-eval izinleri politikanın koruma değerini düşürebilir.
Nonce ve Hash Yaklaşımı
Inline script kullanımı gereken yapılarda nonce veya hash tabanlı CSP yaklaşımı değerlendirilebilir.
CSP değişiklikleri önce raporlama modunda gözlemlenerek gerçek kullanıcı akışlarını bozmadan uygulanabilir.
Security Headers
CSP dışında web uygulamasında uygulanabilecek diğer güvenlik header’ları arasında:
- Strict-Transport-Security,
- X-Content-Type-Options,
- Referrer-Policy,
- Permissions-Policy
bulunabilir.
Header politikası uygulamanın gerçek ihtiyacına göre tasarlanmalıdır.
Dependency Riskleri
Modern uygulamalar binlerce üçüncü taraf dependency içerebilir. Güvenlik ekibinin yalnız kendi yazdığı kodu analiz etmesi yeterli değildir.
Software Composition Analysis araçları:
- bilinen açıkları,
- eski paketleri,
- riskli bağımlılıkları,
- lisans problemlerini
tespit etmeye yardımcı olabilir.
Secret Scanning
API key, database parolası, private key veya cloud credential gibi bilgiler repository içine yazılmamalıdır.
Secret scanning CI/CD ve repository seviyesinde kullanılabilir.
SAST, DAST ve Runtime Güvenliği
Tek bir tarama yöntemi bütün açıkları yakalayamaz.
SAST
Kaynak kod veya derleme aşamasındaki güvenlik problemlerini analiz eder.
DAST
Çalışan uygulamanın dışarıdan davranışını test eder.
Runtime
Production ortamında gerçek saldırı ve anomali sinyallerini izler.
Sürekli Açık Yönetimi
“Tarama yaptık ve raporu kapattık” yaklaşımı yeterli değildir.
Yeni dependency, deploy veya konfigürasyon değişikliği yeni risk üretebilir.
Açık yönetimi:
- tespit,
- risk skorlama,
- önceliklendirme,
- düzeltme,
- tekrar doğrulama
döngüsü olarak ele alınmalıdır.
CVSS Tek Başına Öncelik Değildir
Yüksek CVSS skoru her zaman kurum açısından en kritik risk anlamına gelmez.
İnternete açık olup olmadığı, exploit bulunması, işlenen veri ve sistemin kritikliği de dikkate alınmalıdır.
API Security
Web uygulamasının güvenli frontend’e sahip olması API’nin de güvenli olduğu anlamına gelmez.
API tarafında:
- authentication,
- object-level authorization,
- input validation,
- rate limiting,
- audit logging
uygulanmalıdır.
CI/CD Güvenliği
Deployment pipeline’ın ele geçirilmesi doğrudan production koduna erişim sağlayabilir.
CI/CD sistemlerinde:
- MFA,
- minimum yetki,
- protected branch,
- signed artifact,
- secret isolation
gibi kontroller değerlendirilebilir.
Supply Chain Riski
Risk yalnız şirket çalışanlarından veya uygulama kodundan gelmez. Kullanılan npm paketi, WordPress eklentisi, SaaS servisi veya üçüncü taraf script de saldırı zincirinin parçası olabilir.
Loglama ve Incident Response
Bir olay gerçekleştiğinde yalnız firewall alarmına sahip olmak yeterli değildir.
Kimlik doğrulama, admin hareketleri, API erişimleri ve kritik değişiklikler olay araştırmasına uygun biçimde loglanmalıdır.
Web Güvenliği 2026 Kontrol Listesi
- Yönetici hesaplarında MFA var mı?
- Yetkiler minimum seviyede mi?
- CSP uygulanıyor mu?
- Dependency açıkları otomatik taranıyor mu?
- Secret scanning var mı?
- API authorization test ediliyor mu?
- CI/CD erişimleri sınırlı mı?
- Production logları korunuyor mu?
- Yedekler restore testinden geçiyor mu?
- Incident response prosedürü var mı?
B10 Yaklaşımı
B10 Digital Agency, web güvenliğini tek bir güvenlik eklentisine indirgemez. Uygulama, sunucu, API, erişim, deployment ve loglama katmanlarını birlikte değerlendirir.
Güncel Referans
Zero Trust yaklaşımında NIST SP 800-207 temel mimari referanslardan biri olmaya devam ederken, NIST SP 1800-35 uygulama rehberi gerçek dünya Zero Trust örneklerini ayrıntılı biçimde ele almaktadır.
Sonuç
2026’da web güvenliği bir defalık kontrol değil, sürekli çalışan mühendislik sürecidir. Kimlik, browser politikaları, dependency güvenliği, API yetkilendirmesi ve CI/CD kontrolleri birlikte yürütüldüğünde saldırı yüzeyi daha ölçülebilir hale gelir.
