OWASP Top 10:2025 — Her Risk Kategorisi Aslında Neyi Kapsıyor#

OWASP Top 10 bir farkındalık dokümanıdır; bir standart, bir test planı veya bir uyum kontrol listesi değildir. Topluluk anketi ve katkı sağlanan verilerden çıkarılan geniş bir uzlaşıyı temsil eder. Onu riski önceliklendirmek için ortak bir sözlük olarak kullanın; doğrulanabilir gereksinimler gerektiğinde ASVS'e başvurun.

Bu sürüm OWASP Top 10:2025. Aşağıdaki on kategoriyi okumadan önce 2021 sürümüne göre ne değiştiğini bilmeniz gerekir — çünkü eski listeye göre yazılmış bir sayfa, artık var olmayan kategorileri adlandırır:

• A03 Yazılım Tedarik Zinciri Hataları yeni. Eski "Savunmasız ve Güncel Olmayan Bileşenler" riskini tüm tedarik zinciri hatalarına genişletiyor: kötü niyetli bir geliştirici, ele geçirilmiş bir derleme sistemi, zehirlenmiş bir CI/CD hattı, yeniden paketlenen (terfi ettirilmek yerine) bir artefakt.
• A10 İstisnai Durumların Yanlış Yönetimi yeni: fail-open mantığı, ele alınmayan istisnalar, sızdıran hata mesajları ve serbest bırakılmayan kaynaklar.
• Server-Side Request Forgery (SSRF) artık bağımsız bir kategori değil. CWE'si (CWE-918) A01 Erişim Kontrolü Bozukluğu içinde yer alıyor.
• A09 artık "Güvenlik Günlüğü ve Alarm Hataları" — yeniden adlandırma asıl mesajı veriyor: üzerine kimsenin hareket etmediği günlükleme hiçbir şeyi değiştirmez.
• A07 "Kimlik Belirleme ve" kısmını bıraktı; artık yalnızca "Kimlik Doğrulama Hataları".

On kategori bir bakışta#

A01:2025 — Erişim Kontrolü Bozukluğu#

Erişim kontrolü, kullanıcıların amaçlanan yetkilerinin dışına çıkmaması için politika uygular. #1'de kalıyor ve katkı sağlanan verilerde test edilen her uygulamada bir biçimi vardı. Kapsamı: güvensiz doğrudan nesne referansları (IDOR/BOLA), zorla gezinme, POST/PUT/DELETE üzerinde eksik fonksiyon düzeyi kontrol, yetki yükseltme, JWT kurcalama ve yeniden oynatma, CORS yanlış yapılandırması ve 2025 itibarıyla SSRF — çünkü sunucunun sizin adınıza yaptığı istek de hangi hedeflerin kapsamda olduğuna dair bir yetkilendirme kararıdır.

Test sinyali: her nesne ve her eylem için hem bir izin (kendi kaynağı) hem bir ret (yabancı kaynak) durumu kanıtlayın. Bir dışarıdan geleni tamamen reddeden rota, nesne düzeyi politikasını test etmemiştir — yalnızca fonksiyon düzeyi erişimi denemiştir. Bu tam da sitenin API erişim kontrolü test planı, IDOR/BOLA test planı ve bunun BOLA test matrisi ile otomasyonunda ele aldığı boşluktur.

A02:2025 — Güvenlik Yapılandırma Hatası#

Bu kategori #2'ye yükseliyor ve tanımı bilinçli olarak geniş: yığının herhangi bir parçasının güvensiz kurulması. Yerinde bırakılmış varsayılan hesaplar ve parolalar, gereksiz özellik/port/örnek uygulamalar, kullanıcıya dönen ayrıntılı yığın izleri, eksik güvenlik başlıkları, izin verici bulut depolama ve yükseltilmiş sistemlerde kapatılmış güvenlik özellikleri.

Test sinyali: amaçlananı değil erişilebilir olanı sayın. Dizin listeleme, açıkta .git, yedek dosyalar ve açık yönetim arayüzleri klasik isabetlerdir. Gölge (dokümante edilmemiş) API yüzeyleri bunu kötüleştirir; gölge API varlık envanteri yaklaşımı dağıtım manifestinden değil, gözlemlenen host ve rotalardan başlar.

A03:2025 — Yazılım Tedarik Zinciri Hataları#

Yeni ve topluluk anketinde en üstte. Kapsam "bilinen savunmasız bileşenler"den, yazılımı derleyen, dağıtan ve güncelleyen tüm yola genişledi. Geçişli bağımlılıkları izlemediğinizde, zafiyet taraması yapmadığınızda, CI/CD hattını dağıttığı sistemlerden daha zayıf güvenlikle çalıştırdığınızda, paketleri resmî olmayan kaynaklardan aldığınızda veya kodu yazmakla üretime terfi ettirmek arasında görev ayrımı olmadığında maruz kalırsınız.

Adı geçen örnekler tüm kategoriyi kapsadığı için bilinmeye değer: SolarWinds (2019, ele geçirilmiş bir üretici derlemesi), Log4Shell ve Struts RCE (bileşen zafiyetleri) ve Shai-Hulud npm solucanı (2025) — kendi kendine yayılan, npm token'larını toplayıp kötü niyetli sürümler yeniden yayımlayan bir paket.

Test sinyali: SBOM üretin, geçişli bağımlılıkları takip edin, sürümleri sabitleyin ve doğrulayın (imzalı sağlama toplamları, güvenilir kayıt defterleri). Uygulama tarafında zehirlenmiş bir JavaScript bağımlılığı tam buraya düşer; sitenin prototype pollution çalışması bu zincirin somut olarak sömürülebilen ucudur. Sürüm-CVE eşleşmesinin düz bir örneği CVE-2024-6387 anatomisi yazısında.

A04:2025 — Kriptografik Hatalar#

İki sıra inip #4. Gereken yerde kriptografinin hiç olmaması, kriptografinin zayıf olması ve anahtar sızıntısını kapsar: hızlı fonksiyonlarla hash'lenmiş parolalar, yeniden kullanılan veya koda gömülü anahtarlar, güvensiz modlar, tohumlanmamış rastgelelik ve MD5/SHA1 gibi kullanımdan kalkan ilkeller. 2025 metni ileriye dönük bir not da ekliyor: yüksek riskli sistemler bu on yılın sonuna dek kapsamda olacak şekilde kuantum sonrası göçü planlayın.

Test sinyali: önce veriyi sınıflandırın — etiketlemediğiniz şeyi koruyamazsınız. Sonra ileri gizlilikli TLS 1.2+, kimlik doğrulamalı şifreleme, uyarlanabilir tuzlu parola hash'i (Argon2, scrypt ya da PBKDF2-HMAC-SHA-512) ve kaynak kodda asla görünmeyen anahtarlar isteyin.

A05:2025 — Enjeksiyon#

Enjeksiyon #5'e düşüyor ama her kategoriden fazla CVE sayısını koruyor. Tanım yorumlayıcıdan bağımsız: SQL, NoSQL, OS komutu, ORM, LDAP ve şablon/ifade-dili enjeksiyonu, farklı yorumlayıcılarla aynı hatadır. Siteler arası betik çalıştırma bu kategoriye dahil; LLM prompt injection ise ilgili ama ayrı belgelenmiş bir sınıf olarak işaretleniyor (bkz. OWASP LLM Top 10).

Test sinyali: veriyi komutlardan ayrı tutun — parametreli sorgular, güvenli API'ler, ORM'ler. Her girdi yüzeyini hedefleyin: parametreler, başlıklar, çerezler, JSON, XML ve ORM'in seve seve bir yükleme çevireceği arama parametreleri. Site iki yorumlayıcıyı doğrudan işliyor: NoSQL operatör enjeksiyonu ve XSS lab rehberi.

A06:2025 — Güvensiz Tasarım#

#6'ya düşüyor. Güvensiz tasarım, eksik veya etkisiz kontrol tasarımıdır: iş mantığı kusurları, olmayan hız limitleri, hiç modellenmemiş güven sınırları. Güvenli bir tasarımda hâlâ uygulama hataları olabilir; güvensiz tasarım gereken kontroller hiç tanımlanmadığı için yalnızca uygulama yamasıyla düzeltilemez. Güvenlik sorularıyla hesap kurtarma zayıf bir kimlik kanıtıdır; NIST parola seçerken bilgi tabanlı kimlik doğrulamayı yasaklar ve hesap kurtarmayı ayrı ele alır. Tüm sinemayı tek seferde kiralama kuralı olmayan rezervasyon akışı da başka bir örnektir.

Test sinyali: kritik akışları tehdit modelleyin — kimlik doğrulama, erişim kontrolü, iş mantığı, kritik para/durum geçişleri — ve kullanım durumlarının yanına kötüye kullanım durumlarını yazın.

A07:2025 — Kimlik Doğrulama Hataları#

#7'de. Sistem geçersiz bir kullanıcıyı meşru sanmaya kandırılabiliyorsa vardır: kimlik bilgisi doldurma (credential stuffing) ve parola püskürtme saldırıları, izin verilen varsayılan/zayıf parolalar, ihlalde açığa çıkmış kimlik bilgileriyle oluşturulan hesaplar, bilgi tabanlı kurtarma, eksik ya da etkisiz MFA ve tanımlayıcıları açığa çıkaran veya geçersiz kılamayan oturum yönetimi. 2025 metni ayrıca bir kimlik bilgisinin amaçlanan kullanımını doğrulamayı da ekliyor — token'lar için aud, iss ve scope.

Test sinyali: numaralandırma direncini (tek tip mesajlar), kendisi bir DoS'a dönüşmeyen başarısız deneme kısıtlamasını, girişte oturum yenilemeyi ve çıkışta sunucu taraflı geçersiz kılmayı kontrol edin. "Kimlik doğrulayıcının sahiplenmeniz gereken bir sınır olduğu" fikrinin masaüstü karşılığı sitenin Linux auth UI yazısında işleniyor.

A08:2025 — Yazılım veya Veri Bütünlüğü Hataları#

#8'de kalıyor, adı "Yazılım veya Veri" olarak netleşiyor. A03'ün alt katmanıdır: yazılım güncellemeleri, serileştirilmiş veri veya CI/CD artefaktları hakkında bütünlüğünü doğrulamadan varsayım yapmak. Güvenilmeyen verinin deserialize edilmesi, bütünlük kontrolü olmadan eklenti ya da CDN betiği tüketilmesi ve kötü kontrol edilen mass assignment (CWE-915) burada.

Test sinyali: artefaktları imzalayın ve doğrulayın; güvenilmeyen veride güvensiz nesne deserialization'ından kaçının. İçeriğin ayrıştırılması gerekiyorsa yalnızca veri işleyen bir format, şema doğrulaması ve boyut sınırları kullanın. Çalışma anında çekilen her şeyde bütünlük kontrolü isteyin. JavaScript tarafında güvenilmeyen öznitelik değişikliği ailesi prototype pollution malzemesiyle örtüşür.

A09:2025 — Güvenlik Günlüğü ve Alarm Hataları#

#9'da ve OWASP'ın da belirttiği gibi test edilmesi zor olduğu için veride yapısal olarak yetersiz temsil ediliyor. "Alarm"a yeniden adlandırma tüm mesaj: hiç kimsenin üzerine gitmediği günlükleme bir olayı durdurmaz. Denetlenebilir olaylar (girişler, başarısızlıklar, yüksek değerli işlemler) günlüklenmiyorsa, günlük bütünlüğü korunmuyorsa, taramalar alarm tetiklemiyorsa, alarm eşikleri yoksa ya da günlüklerin kendisi bir sızıntı oluyorsa bu kategori vardır.

Test sinyali: her güvenlik kontrolünün başarısını ve başarısızlığını üzerine hareket edilecek yeterli aktör bağlamıyla günlükleyin, günlük bütünlüğünü (yalnızca-ekle) koruyun ve eşikleri gerçek bir müdahale yoluna bağlayın. İki site yazısı bu disiplini baştan sona taşıyor: güvenlik günlükleme tasarımı ve reddedilen istek alarm triyajı.

A10:2025 — İstisnai Durumların Yanlış Yönetimi#

2025 için yeni ve eskiden "kötü kod kalitesi" diye geçiştirilen 24 CWE'yi topluyor. Başarısızlığın üç biçimi var: uygulama sıra dışı durumu önlemiyor, tespit etmiyor ya da kötü yanıtlıyor. Fail-open mantığı, ele alınmayan istisnalar, hassas içerikli hata mesajları (CWE-209), kaynak sızıntıları, NULL referansları ve çok adımlı işlemlerin anormal yolda tam geri alınmadığı için durumu bozması bu şekilde ortaya çıkar.

Test sinyali: istisnaları oluştukları yerde ele alın, arka plan olarak global bir handler ekleyin, kısmi işlemlerde fail-closed davranın ve dövülebilecek her şeye hız limiti koyun. CVE-2024-6387 arkasındaki sinyal işleme yarışı, işletim sistemi düzeyinde bir istisnai durum hatasıdır ve "daima fail-closed" kuralı günlükleme yazısında pekiştirilir.

Bunu nasıl sorumlu kullanmalı#

• Bu farkındalıktır, doğrulama değil. Top 10 risk kategorilerini adlandırır; ASVS test edilebilir gereksinimleri verir. Bir Top 10 geçişini güvenlik onayı olarak sunmayın.
• Sıralama sizin sıralamanız değil. Konumlar katkı sağlanan veri ile topluluk anketinden gelir. #9'daki bir kategori, müşteri verinizi kaybettiren kategori olabilir.
• Etiketi değil CWE'yi okuyun. Kategori adları ve konumları sürümler arasında değişir (SSRF taşındı; "bileşenler" "tedarik zinciri" oldu). Kararlı birleştirme anahtarı CWE'dir.
• "Uygulamaların %100'ü" test edilen kümedir. Buradaki istatistikler katkı sağlanan örneklemi tanımlar, her yerdeki yazılımı değil.

İlgili Araştırma ve İç Referanslar#

• API Erişim Kontrolü Test Planı - Nesne ve fonksiyon düzeyi yetkilendirme kontrolleri (A01).
• IDOR/BOLA Test Planı - Referans tabanlı erişim kontrolü hatası, baştan sona.
• BOLA Test Matrisi Otomasyonu - Rol × eylem × veri matrisini otomatik taramaya taşımak.
• Güvenlik Günlükleme Tasarımı - Denetim şeması, bütünlük ve fail-closed davranış (A09/A10).
• Reddedilen İstek Alarm Triyajı - Ret akışlarını gürültü yerine sinyale çevirmek (A09).
• Gölge API Varlık Envanteri - Gerçekte açıkta olanı saymak (A02).
• Prototype Pollution - Somut olarak sömürülebilen bir JavaScript bağımlılık saldırısı (A03/A08).
• CVE-2024-6387 Anatomisi - Sürüm-CVE riski ve sinyal işleme yarışı (A03/A10).
• NoSQL Operatör Enjeksiyonu ve XSS Lab Rehberi - İki yorumlayıcı, tek hata sınıfı (A05).
• Linux Masaüstünde Yetkilendirme ve Kimlik Doğrulama Arayüzlerinin Güvenlik Mimarisi - Kimlik doğrulama sınırının fiziksel olarak nerede durduğu (A07).

Birincil kaynak: OWASP Top 10:2025 sürümü ve kategori sayfaları. Farkındalık listesi yerine doğrulanabilir bir gereksinim kümesi gerektiğinde OWASP ASVS'i; LLM uygulamaları için prompt injection'ı ayrı ele alan OWASP LLM Top 10'u kullanın. Bu sayfa ilgili kamuya açık malzemenin editoryal bir okumasıdır ve sitenin kendi derinlemesine yazılarına çapraz referans verir; bir OWASP yayını değildir ve ne o dokümanın ne de gerçek bir değerlendirmenin yerini tutar.