OWASP Top 10 listesinin sekizinci sürümü olan Top 10:2025, 2021'den bu yana kullandığımız listenin yerini aldı. Yeni liste 2,8 milyondan fazla uygulamanın test verisine ve NVD'den CWE'lere eşlenmiş yaklaşık 175 bin CVE kaydına dayanıyor. Aşağıda değişiklikleri ve küçük-orta ölçekli bir web uygulamasında nereden başlanabileceğini özetledim.
2025 listesi
| Sıra | Kategori | 2021'e göre |
|---|---|---|
| A01 | Broken Access Control (Erişim kontrolü hataları) | Yine 1. sırada; SSRF artık bu kategoride |
| A02 | Security Misconfiguration (Yanlış yapılandırma) | 5. sıradan 2. sıraya çıktı |
| A03 | Software Supply Chain Failures (Yazılım tedarik zinciri) | Yeni; eski "güncel olmayan bileşenler" kategorisini genişletiyor |
| A04 | Cryptographic Failures (Kriptografi hataları) | 2. sıradan 4. sıraya indi |
| A05 | Injection (Enjeksiyon) | 3. sıradan 5. sıraya indi |
| A06 | Insecure Design (Güvensiz tasarım) | 4. sıradan 6. sıraya indi |
| A07 | Authentication Failures (Kimlik doğrulama hataları) | Aynı sırada, adı kısaldı |
| A08 | Software or Data Integrity Failures | Aynı sırada |
| A09 | Security Logging & Alerting Failures | Aynı sırada; vurgu "izleme"den "alarm"a kaydı |
| A10 | Mishandling of Exceptional Conditions (İstisnai durumların yanlış ele alınması) | Yeni; hata yönetimi, mantık hataları ve "fail open" |
Öne çıkan üç değişiklik
- SSRF ayrı bir madde değil. Sunucunun kullanıcı kontrolündeki bir adrese istek atması artık bir erişim kontrolü sorunu olarak ele alınıyor. Mantıklı: SSRF'de asıl sorun, uygulamanın kendi yetkisiyle iç ağa erişmesi.
- Tedarik zinciri üst sıralarda. A03 ve A09, verilerden değil topluluk anketinden seçilen iki kategori. Bu yıl npm ve PyPI'de yaşanan solucan dalgaları düşünülünce yerinde bir seçim.
- Hata yönetimi ilk kez listede. Bir istisnada kontrolün atlanması, hata mesajında iç bilgilerin sızması ya da beklenmedik durumda "izin ver" yönüne düşen kod artık ayrı bir risk kategorisi.
Kendi uygulamanızda ilk hafta için kontrol listesi
- A01: Her yönetim ve API ucunda yetki kontrolünün sunucu tarafında yapıldığını doğrulayın. Bir kullanıcının ID'sini başka bir kullanıcınınkiyle değiştirerek (IDOR) birkaç istek deneyin. Sunucunuz dış adreslere istek atıyorsa (resim indirme, webhook) iç ağ adreslerini engelleyin.
- A02: Hata ayıklama modu, dizin listeleme, varsayılan parolalar, açık
.gitve.envdosyaları. Kendi sitenize/.envve/.git/configistekleri atıp 404 döndüğünü kontrol edin. - A03: Kilit dosyası (lockfile) kullanın, bağımlılıkları sürüme sabitleyin, yeni yayımlanan sürümleri hemen almayın.
- A07: Giriş sayfasında hız sınırı ve hesap kilitleme var mı? Yöneticiler için iki adımlı doğrulama zorunlu mu?
- A09: Başarısız girişler kayıt altına alınıyor mu ve biri bunları gerçekten görüyor mu? Kayıt tutmak yetmiyor, alarm üretmek gerekiyor.
- A10: Kodda
catchbloklarına bakın: istisna yakalandığında yetki kontrolü atlanıyor mu? Kullanıcıya yığın izi (stack trace) gösteriliyor mu?
Siz kendi projelerinizde hangi kategoriyle en çok karşılaşıyorsunuz? Özellikle A10 için gerçek hayattan "fail open" örnekleri paylaşırsanız ayrı bir konuda toplayabiliriz.
