<

OWASP Top 10 2025: Yapılandırma Hataları Neden İkinci Sıraya Çıktı

OWASP Top 10'un 2025 sürümü, listenin sekizinci baskısı. Bizim gibi hem mobil hem backend tarafında iş yapan ekipler için asıl haber sıralamanın kendisi değil, sıralamanın nedeni. Çünkü listenin tepesine yaklaşan kategoriler, artık klasik kod hatalarından çok kurulum ve tedarik zinciri kararlarıyla ilgili.

Yeni sıralama ve dikkat çeken hareketler

  • A01 – Broken Access Control (yerini korudu, SSRF bu başlık altında birleştirildi)
  • A02 – Security Misconfiguration (5'ten 2'ye yükseldi)
  • A03 – Software Supply Chain Failures (eski "eski/zafiyetli bileşenler" başlığının genişletilmiş hali)
  • A04 – Cryptographic Failures (2'den 4'e geriledi)
  • A05 – Injection (3'ten 5'e geriledi)
  • A06 – Insecure Design
  • A07 – Authentication Failures
  • A08 – Software or Data Integrity Failures
  • A09 – Security Logging & Alerting Failures
  • A10 – Mishandling of Exceptional Conditions (tamamen yeni)

Injection gerilemesi iyi haber mi

Kısmen. Injection'ın beşinci sıraya düşmesi, saldırıların azalmasından değil, framework'lerin işini iyi yapmasından kaynaklanıyor. Laravel'de Eloquent, düz PHP'de PDO ile hazırlanmış sorgular kullanıyorsanız SQL injection yüzeyiniz gerçekten küçülüyor. Ama denetimlerde hâlâ aynı yeri buluyoruz: rapor ekranlarındaki dinamik ORDER BY ve dinamik kolon adları. Bu alanlar parametre bağlama ile korunamaz; beyaz liste gerekir.

Yapılandırma hatası neden bu kadar yukarıda

Sahada gördüğümüz en sık üç kalıp şunlar: üretimde açık kalmış hata ayıklama modu, varsayılan kimlik bilgileriyle bırakılmış yönetim panelleri ve gereğinden fazla geniş izinlerle çalışan uygulama veritabanı kullanıcısı. Üçü de bir zafiyet değil, bir karar eksikliği. Bizim yaklaşımımız, yapılandırmayı kod kadar ciddiye almak: ortam değişkenlerinin tamamı sürüm kontrolünde bir şablon dosyasıyla belgelenir, üretim dağıtımı hata ayıklama modu açıkken başarısız olacak şekilde bir kontrol adımı içerir.

Yapılandırma hatalarının üç sık kalıbı ile bunlara karşı uyguladığımız yaklaşımın karşılaştırması.
Üçü de bir zafiyet değil, bir karar eksikliği.

A10 gerçekten yeni bir bakış açısı

Listeye yeni giren "istisnai durumların yönetilmemesi" başlığı, uzun süredir konuştuğumuz bir şeyi resmileştiriyor: hata yönetimi bir güvenlik konusudur. Ödeme servisi zaman aşımına düştüğünde siparişi "başarılı" sayan bir akış, teknik olarak bir hata yönetimi kusuru, pratikte ise doğrudan para kaybı. Benzer şekilde, yakalanmayan bir istisnanın kullanıcıya yığın izi göstermesi bilgi sızıntısıdır.

Kontrol listemiz kısa: her dış çağrının zaman aşımı tanımlı olacak, her catch bloğu ya hatayı işleyecek ya da yukarı fırlatacak (sessizce yutmayacak), ve başarısızlık durumunda sistemin varsayılan davranışı "izin verme" olacak.

Tedarik zinciri: en zor kısım

A03'ün genişletilmesi, "composer.json'da kaç paket var" sorusunu güvenlik sorusuna dönüştürdü. Bir Flutter projesinde pub bağımlılıklarının geçişli ağacı kolayca yüzlerce pakete çıkabiliyor. Minimum uygulanabilir yaklaşım: kilit dosyalarını kesinlikle sürüm kontrolünde tutmak, bağımlılık güncellemelerini otomatik ama gözden geçirmeli hale getirmek ve her sürüm için bir malzeme listesi (SBOM) üretmek.

Erişim kontrolü hâlâ birinci, çünkü test edilmesi zor

A01'in yerini koruması tesadüf değil. Erişim kontrolü, otomatik araçların en zor yakaladığı zafiyet sınıfı; çünkü "bu kullanıcı bu kaydı görmeli mi" sorusunun cevabı koddan değil iş kuralından geliyor. Tarayıcı bir 200 yanıtı görüyor ve bunu normal sayıyor.

Denetimlerde uyguladığımız yöntem elle ve basit: iki farklı müşteriye ait iki hesap açıyoruz, birinin kayıt kimliğini alıp diğerinin oturumuyla istiyoruz. Bu tek test, sahada bulduğumuz yetki açıklarının büyük kısmını ortaya çıkarıyor. Kalıcı çözüm ise kod tarafında: sorguya sahiplik koşulunu (örneğin where firma_id = ?) her seferinde elle eklemek yerine, sorgu kapsamını (scope) veya global bir filtreyi zorunlu hale getirmek. Elle eklenen koşullar bir gün unutuluyor; framework seviyesine taşınan kural unutulmuyor.

Erişim kontrolü testi: iki hesap açılır, kayıt kimliği diğer oturumla istenir, kalıcı çözüm olarak scope zorunlu kılınır.
Tek test, bulunan yetki açıklarının büyük kısmını ortaya çıkarıyor.

Aynı mantık kayıt ve alarm tarafı (A09) için de geçerli: kritik uçlarda yetki reddi olaylarını kaydetmiyorsanız, bir saldırı denemesini deneme sırasında değil sonuçları ortaya çıktığında öğreniyorsunuz.

Mevcut sisteminizi bu on başlığa karşı gözden geçirmek istiyorsanız, bu tam olarak sık yaptığımız işlerden biri. İletişim sayfamızdan bize ulaşın; genellikle ilk denetimde çıkan bulguların büyük kısmı bir haftalık iş yüküyle kapanabiliyor.

📅 Yayınlanma:  ·  Yakup Zengin