OWASP Top 10 (2025) Kapsamlı Uygulama Güvenliği ve Savunma Kılavuzu

1. Giriş: 2021’den 2025’e Ne Değişti?

OWASP Top 10, web uygulamalarındaki en kritik risk kategorilerinin referans listesidir. 2025 sürümündeki başlıca değişiklikler:

2025	Değişiklik
A02 Security Misconfiguration	5. sıradan 2. sıraya yükseldi.
A03 Software Supply Chain Failures	Yeni kapsam. 2021’deki “Vulnerable and Outdated Components” kategorisini derleme, dağıtım ve bağımlılık zincirinin tamamını kapsayacak şekilde genişletir.
A10 Mishandling of Exceptional Conditions	Yeni kategori. Hatalı hata yönetimi, “fail-open” davranışı ve mantık hataları.
SSRF	Ayrı kategori olmaktan çıktı, A01 Broken Access Control altına alındı.
A07 / A09	Adları “Authentication Failures” ve “Security Logging and Alerting Failures” olarak güncellendi.

Risk: Kullanıcının yetkisi dışındaki veri veya işlevlere erişmesi (IDOR/BOLA, zorunlu gezinme, yetki yükseltme). 2025’te SSRF de bu kategoriye dahil.
Savunma:
- Varsayılan olarak tüm erişimleri engelleyin (deny by default), yetkiyi her istekte sunucu tarafında doğrulayın.
- Rota düzeyi yerine nesne/kaynak düzeyinde yetki kontrolü (ABAC/ReBAC) uygulayın.
- CORS’ta Access-Control-Allow-Origin değerini yansıtmayın; kimlik bilgisi taşıyan isteklerde yalnızca açık allowlist kullanın.
- SSRF: Giden istekleri domain/IP allowlist’i ile sınırlandırın, dahili aralıkları (127.0.0.0/8, 10.0.0.0/8, 169.254.169.254) ağ düzeyinde engelleyin, bulutta IMDSv2 zorunlu kılın.

Risk: Varsayılan parolalar, açık debug modları ve stack trace’ler, gereksiz servis/metotlar, eksik güvenlik başlıkları, herkese açık bulut depolama.
Savunma:
- Ortamları tekrarlanabilir, sıkılaştırılmış şablonlarla (IaC) kurun ve yapılandırma sapmasını otomatik denetleyin.
- Üretimde debug modlarını kapatın; hata yanıtlarında iç ayrıntı döndürmeyin.
- CSP, HSTS ve frame-ancestors gibi güvenlik başlıklarını eksiksiz yapılandırın.

Risk: Savunmasız veya güncel olmayan bağımlılıklar, ele geçirilmiş paketler (typosquatting, bağımlılık karışıklığı), güvensiz CI/CD boru hatları ve derleme ortamları.
Savunma:
- SBOM üretin ve bağımlılıkları sürekli tarayın (ör. Trivy, OSV-Scanner, Dependabot).
- Lock dosyalarıyla sürümleri sabitleyin; özel paket adları için kapsamlı (scoped) kayıt defteri kullanın.
- Derleme çıktılarını imzalayın ve doğrulayın (Sigstore/Cosign, SLSA provenance).
- CI/CD’de en az yetki uygulayın; üçüncü taraf eylemleri commit hash’e sabitleyin.

Risk: Hassas verinin açık metin iletilmesi veya saklanması, zayıf algoritmalar (MD5, SHA-1, DES), hatalı anahtar yönetimi.
Savunma:
- Transit veride TLS 1.2+ (tercihen 1.3) ve HSTS kullanın.
- Parolalarda Argon2id veya bcrypt (yeterli maliyet faktörüyle) kullanın.
- Simetrik şifrelemede AES-GCM veya ChaCha20-Poly1305 gibi kimlik doğrulamalı şifreleri tercih edin; anahtarları KMS/HSM’de tutun.

Risk: SQL, NoSQL, OS komut, LDAP, şablon (SSTI) enjeksiyonları ve XSS.
Savunma:
- Veritabanı işlemlerinde parametreli sorgular kullanın.
- Çıktıyı bağlama uygun şekilde kodlayın (HTML, attribute, JS, URL); CSP ile XSS etkisini sınırlayın.
- eval, exec ve güvensiz deserialization fonksiyonlarından kaçının.

Risk: Kodlama hatası değil, tasarım düzeyindeki eksiklikler: sınırsız kupon kullanımı, oran sınırı olmayan parola sıfırlama, iş mantığı atlatmaları.
Savunma:
- Tehdit modellemeyi (STRIDE vb.) SDLC’nin parçası yapın.
- Kritik iş akışlarında oran sınırlama, idempotency ve ek onay adımları tasarlayın.

Risk: Zayıf parola politikaları, credential stuffing, oturum sabitleme, MFA eksikliği.
Savunma:
- NIST SP 800-63B’ye uygun parola politikası uygulayın, sızmış parola listelerine karşı kontrol edin.
- MFA’yı zorunlu kılın; mümkünse phishing’e dayanıklı FIDO2/passkey kullanın.
- Oturum kimliğini girişten sonra yenileyin, oturumlara süre sınırı koyun.

Risk: İmzasız güncellemeler, güvenilmeyen kaynaktan kod/veri yüklenmesi, güvensiz deserialization, bütünlüğü doğrulanmayan token’lar.
Savunma:
- Güncelleme ve eklentilerin imzasını doğrulayın; CDN’den yüklenen betiklerde Subresource Integrity (SRI) kullanın.
- JWT doğrulamasında algoritmayı sunucu tarafında sabitleyin, alg: none kabul etmeyin.

Risk: Güvenlik olaylarının loglanmaması veya loglansa bile alarm üretilmemesi; saldırının aylar sonra fark edilmesi.
Savunma:
- Kimlik doğrulama, yetki reddi ve kritik işlem olaylarını merkezi SIEM’e gönderin.
- Loglardan eyleme dönüştürülebilir alarmlar üretin ve olay müdahale sürecine bağlayın.
- Log bütünlüğünü koruyun (append-only depolama); loglara hassas veri yazmayın.

Risk: Beklenmedik girdi, zaman aşımı veya kaynak tükenmesinde uygulamanın güvensiz davranması: “fail-open” yetki kontrolleri, yarım kalan işlemler, hata mesajlarıyla bilgi sızması.
Savunma:
- Hata durumunda güvenli tarafa düşün (fail closed): yetki kontrolü hata verirse erişimi reddedin.
- Çok adımlı işlemleri atomik yapın, hata durumunda geri alın (transaction/rollback).
- Hataları merkezi olarak yakalayın; kullanıcıya genel mesaj dönün, ayrıntıyı yalnızca loglayın.