OWASP Top 10 2025 riskleri, modern web uygulamalarının güvenlik durumunu değerlendirmek isteyen ekipler için önemli bir başlangıç noktasıdır. Bir uygulamanın hızlı ve güzel tasarlanmış olması, güvenli olduğu anlamına gelmez. Giriş yapan bir kullanıcının başka müşterinin kaydını görmesi, yanlış yapılandırılmış bir API’nin hassas verileri açması veya güncellenmemiş bir paketin üretim sistemini etkilemesi teknik ve ticari sonuçlar doğurabilir. Bu nedenle güvenlik kontrolü yalnızca yayından önce yapılan tek bir tarama değil; tasarım, geliştirme, dağıtım ve izleme süreçlerinin tamamıdır.
OWASP Top 10 2025, web uygulamalarında kritik güvenlik risklerini sınıflandıran güncel farkındalık rehberidir. 2026’da geliştirilen ürünlerde de temel referans olarak kullanılabilir. Liste bir sızma testi raporu veya “10 maddeyi kapattım, güvenli oldum” sertifikası değildir. Risk alanlarını görünür kılan bir başlangıç çerçevesidir. Daha ayrıntılı teknik doğrulama için OWASP Application Security Verification Standard (ASVS) gereksinimleri kullanılabilir. Kaynak: OWASP Top 10:2025.
Bu yazıda neler bulacaksınız?
- OWASP Top 10:2025’in güncel on risk kategorisi
- Her başlığın günlük uygulamada nasıl ortaya çıktığı
- ASP.NET Core, API ve SaaS uygulamaları için güvenli tasarım önerileri
- CI/CD, kod incelemesi ve test otomasyonuna eklenebilecek kontroller
- Penetrasyon testi, zafiyet taraması ve ASVS arasındaki farklar
- Yayına çıkmadan önce kullanılabilecek öncelikli kontrol listesi
OWASP Top 10 2025 risk listesi: Güncel 10 kategori
| Kod | Risk | İşletme açısından örnek etkisi |
|---|---|---|
| A01 | Broken Access Control — Bozuk erişim kontrolü | Başka kullanıcının müşteri dosyasına erişim |
| A02 | Security Misconfiguration — Güvenlik yanlış yapılandırması | Açık yönetim paneli veya tehlikeli varsayılan ayar |
| A03 | Software Supply Chain Failures — Yazılım tedarik zinciri hataları | Güvenilmeyen paket veya ele geçirilmiş build hattı |
| A04 | Cryptographic Failures — Kriptografik hatalar | Hassas verinin uygun korunmaması |
| A05 | Injection — Enjeksiyon | Güvenilmeyen girdinin komut/sorgu gibi işlenmesi |
| A06 | Insecure Design — Güvensiz tasarım | İş akışında işlem sınırlarının bulunmaması |
| A07 | Authentication Failures — Kimlik doğrulama hataları | Hesap devralma veya oturum zafiyeti |
| A08 | Software or Data Integrity Failures — Yazılım/veri bütünlüğü hataları | Doğrulanmamış güncelleme ya da veri işleme |
| A09 | Security Logging & Alerting Failures — Kayıt ve alarm hataları | İhlalin uzun süre fark edilmemesi |
| A10 | Mishandling of Exceptional Conditions — İstisnai durumların yanlış yönetimi | Hata anında yetkisiz işlem veya bilgi sızıntısı |
Not: A03 ve A10 bu sürümde öne çıkan yeni/genişleyen kategorilerdir. Eski 2021 listesinin başlıklarını doğrudan 2025 diye yayımlamak güncel ve doğru bir anlatım değildir.
1. Bozuk erişim kontrolü: “Giriş yaptım” yeterli değil
Kullanıcı kimliğinin doğrulanmış olması, o kullanıcının tüm kayıtları görebileceği anlamına gelmez. Örneğin GET /api/orders/125 isteğinde, 125 numaralı siparişin ilgili kullanıcı veya kiracıya ait olup olmadığı sunucu tarafında kontrol edilmelidir. İstemci arayüzünde bir düğmeyi gizlemek yetkilendirme değildir. API, arka plan işleri ve dışa aktarma uç noktaları da aynı ilkeyi izlemelidir.
Önlem: Kaynak düzeyinde yetkilendirme kuralları, tenant sınırları, negatif test senaryoları ve varsayılan reddetme politikası uygulayın. ASP.NET Core projelerinde rol kontrolünün yanında resource-based authorization kullanımını değerlendirin.
2. Yanlış yapılandırmalar: Görünmez ama yaygın
Üretimde açık hata ayrıntıları, varsayılan hesaplar, aşırı izinli depolama alanları, hatalı CORS kuralları ve internete açık yönetim servisleri risk oluşturabilir. Konfigürasyonların koddan ayrı tutulması kadar güvenli varsayılanlarla dağıtılması da önemlidir.
Önlem: Ortam bazlı ayar incelemesi, gizli anahtarların güvenli yönetimi, zorunlu HTTPS ve merkezi konfigürasyon denetimi uygulayın. Test ortamının üretim verisini paylaşmadığını doğrulayın.
3. Yazılım tedarik zinciri: Kullandığınız paket de saldırı yüzeyidir
NuGet, npm, container imajları, CI/CD araçları ve üçüncü taraf entegrasyonlar uygulamanın parçasıdır. Bir bileşenin güncel olması tek başına yeterli değildir; kaynağının güvenilirliği ve build hattının korunması gerekir.
Önlem: Bağımlılık envanteri ve mümkünse SBOM tutun; güvenilir kayıt kaynakları kullanın, sabitlenmiş sürüm stratejisi geliştirin, CI/CD erişimini kısıtlayın ve zafiyet güncellemelerini risk sırasına alın.
4–6. Kriptografi, enjeksiyon ve güvensiz tasarım
Kriptografik hatalar: Parola gibi sırlar düz metin veya geri çözülebilir biçimde saklanmamalıdır. Uygun parola karma algoritmaları, güvenli anahtar yönetimi ve aktarımda şifreleme kullanın.
Enjeksiyon: SQL sorgularını birleştirilmiş kullanıcı girdisiyle kurmak yerine parametreli sorgular ve doğru API’ler kullanın. HTML çıktıları bağlama uygun biçimde kodlayın; kullanıcı verisini komut olarak çalıştırmayın.
Güvensiz tasarım: Kod hatasından önce, iş kuralının kendisi güvensiz olabilir. Tek kullanımlık indirim kodunun sınırsız kullanılabilmesi veya kritik bir işleme onay sınırı konmaması buna örnektir. Tehdit modellemesi ve kötüye kullanım senaryolarını geliştirme başlangıcına taşıyın.
7–10. Kimlik doğrulama, bütünlük, loglar ve hata yönetimi
Kimlik doğrulama: Güvenli oturum çerezleri (HttpOnly, Secure, uygun SameSite), güçlü MFA, oturum süresi ve şüpheli giriş algılama önemlidir. Kimlik doğrulama ile yetkilendirmeyi karıştırmayın.
Bütünlük: Yazılım güncellemeleri ve veri işleme akışlarında kaynağı, imzayı veya beklenen bütünlüğü doğrulayın. Güvenilmeyen verileri kod ya da yetkili talimat gibi değerlendirmeyin.
Log ve uyarı: Başarısız girişleri, yetki değişikliklerini ve kritik veri işlemlerini izleyin. Log tutmak tek başına yeterli değildir; anlamlı bir alarmın sorumlusu ve müdahale akışı bulunmalıdır. Logların içinde parola ve erişim belirteci tutmayın.
İstisnai durumlar: Beklenmeyen hata oluştuğunda sistem “başarısız olursa izin ver” davranışına geçmemelidir. Hata mesajlarında hassas ayrıntıları dışarı vermeyin; işlem bütünlüğünü sağlayın, güvenli biçimde durun ve iz bırakın.
10 risk için geliştirici odaklı doğrulama örnekleri
Yukarıdaki başlıkları bir kontrol listesine dönüştürmek için her riskin somut bir kabul kriteri olmalıdır. Aşağıdaki örnekler savunma ve test planlaması içindir; bir müşterinin veya üçüncü tarafın sisteminde izinsiz test yapma yetkisi vermez.
A01 — Erişim kontrolünde tenant ayrımını test edin
İki farklı müşteri hesabı ve iki farklı kullanıcı rolüyle aynı API uç noktalarını sınayın. Bir müşterinin siparişini başka müşterinin görüntüleyemediğini, güncelleyemediğini veya dışa aktaramadığını kontrol edin. Kuralın yalnızca arayüzde değil sunucu tarafında zorunlu olması gerekir. ASP.NET Core projelerinde kaynak düzeyi yetkilendirme ve kullanıcı kimliğinden sunucuda türetilmiş tenant bağlamı kullanın. İstemcinin istekte gönderdiği tenant kimliğine tek başına güvenmeyin.
A02 — Üretim konfigürasyonunu otomatik denetleyin
Debug hata sayfaları, varsayılan parolalar, açık depolama izinleri, gereksiz HTTP metotları, aşırı geniş CORS ve yanlış yapılandırılmış proxy kuralları her dağıtımda kontrol edilebilir. İç IP adresini veya connection string’i hata yanıtında göstermediğinizi doğrulayın. Sağlıklı bir konfigürasyon kontrolü yalnızca ayarların varlığına değil, üretimde gerçekten uygulanan değerlere bakmalıdır.
A03 — Bağımlılık ve build hattını koruyun
NuGet, npm, container taban imajı ve CI/CD aracı birer tedarik zinciri bileşenidir. Dağıtılan sürüm için yazılım bileşen envanteri (SBOM), sürüm kilitleme yaklaşımı ve bağımlılık zafiyet takibi oluşturun. Build sistemi erişimi, paket yayımlama yetkisi ve imzalama anahtarları korunsun. Bir bağımlılık zafiyeti duyurulduğunda hangi servislerin etkilendiğini dakikalar içinde belirlemek gerçek bir olgunluk göstergesidir.
A04 — Kriptografiyi anahtar yönetimiyle birlikte inceleyin
HTTPS kullanımı önemlidir ama yeterli değildir. Parola karması, oturum belirteçleri, şifreleme anahtarlarının saklanması, erişim yetkisi ve anahtar rotasyonu bir bütün olarak tasarlanmalıdır. Örneğin production anahtarının kaynak kod deposuna yazılması, güçlü algoritma kullanılmış olsa bile büyük güvenlik riski oluşturabilir. Yedeklerin şifreleme anahtarları da kurtarma planında yönetilmelidir.
A05 — Enjeksiyona karşı parametre ve çıktı bağlamını ayırın
SQL sorgularını kullanıcı girdisiyle string birleştirerek kurmayın; parametreli sorgular veya güvenilir ORM yaklaşımları kullanın. Kullanıcı içeriği HTML’de gösterilecekse bağlama uygun çıktı kodlama ve içerik güvenlik ilkeleri uygulayın. Dosya adı, arama ifadesi, sıralama alanı veya webhook parametresi gibi ikincil girdiler de incelemeye dahil edilmelidir. Ön uç doğrulaması backend doğrulamasını ikame etmez.
A06 — Güvensiz iş kuralını tehdit modelinde arayın
Tek kullanımlık promosyon kodunun sınırsız uygulanabilmesi, ödeme alıcısı değişikliğinin onaysız yapılması veya stok miktarının eşzamanlı isteklerle yanlış güncellenmesi yalnızca sözdizimi kontrolüyle yakalanmayabilir. Ürün ekibiyle birlikte “kötüye kullanım senaryosu” atölyesi düzenleyin. Kim neyi, ne sıklıkta, hangi şartla yapabilmeli sorusunu tasarım başında cevaplayın.
A07 — Kimlik doğrulamayı uçtan uca sınayın
MFA, oturum süresi, hesap kurtarma, oturum iptali, cihaz güveni ve parola deneme sınırlaması birlikte değerlendirilmelidir. Kullanıcı çıkış yaptıktan veya parola sıfırladıktan sonra eski oturumun devam edip etmediğini kontrol edin. Oturum çerezlerinde HttpOnly, Secure ve uygun SameSite tercihleri önemli katmanlardır; ancak çerez özelliği yetki kontrolü hatasını çözmez.
A08 — Dış verinin bütünlüğünü doğrulayın
Ödeme sağlayıcısından gelen webhook, güncelleme paketi veya CI dağıtım çıktısı işleme alınmadan önce beklenen kaynaktan geldiği doğrulanmalıdır. Örneğin bir ödeme bildiriminin imza kontrolü ve yinelenen olaylara karşı idempotent işleme tasarımı gerektirebileceğini unutmayın. Başarılı bir HTTP isteği, verinin güvenilir olduğu anlamına gelmez.
A09 — Alarmın gerçekten bir müdahaleye dönüştüğünü ölçün
Kritik yönetici oturumu, beklenmedik rol değişikliği, büyük ölçekli veri dışa aktarımı veya tekrarlanan kimlik denemeleri loglanmalıdır. Daha önemlisi, uygun alarm kuralları doğru ekibe ulaşmalı ve takip kaydı açılmalıdır. Logların içinde parola, token ve müşteri sırrı gibi bilgileri saklamak yeni bir risk yaratabilir. Örnek bir alarmı test ortamında güvenli biçimde tetikleyip süreci baştan sona doğrulayın.
A10 — Hata anında varsayılan reddetme davranışını koruyun
Yetki kontrol servisi yanıt vermediğinde erişimin açık kalması, ödeme servisinde zaman aşımı olduğunda siparişin iki kez işlenmesi veya bağımlı bir servisin bozuk yanıtıyla hassas hata bilgisi sızdırılması istisnai durum tasarımıdır. Hatalı koşullarda güvenli duruş, idempotent işlemler, rollback ve yeterli gözlemleme önceden tanımlanmalıdır.
OWASP Top 10, ASVS ve pentest: Hangisi ne işe yarar?
Top 10 bir risk farkındalığı sınıflandırmasıdır. OWASP ASVS 5.0, uygulama güvenlik gereksinimlerini daha ayrıntılı ve doğrulanabilir hale getirir. OWASP Web Security Testing Guide (WSTG) ise test yaklaşımını destekler. Yetkili bir penetrasyon testi bunlardan yararlanıp gerçek ürününüzün mimarisine, iş akışına ve erişim kapsamına göre bulgular üretir. Otomatik tarama bütün bu çalışmaların yerini tutmaz. Kaynak: OWASP ASVS.
Özellikle çok kiracılı SaaS yazılımlarında tenant ayrımı, davet bağlantıları, servis hesapları, API yetkileri, dosya yükleme ve dışa aktarma akışları test planına yazılmalıdır. Sızma testinin teslimi yalnızca bulgu listesi olmamalı; sorumlu ekip, kapanış tarihi ve yeniden test kanıtı içermelidir.
CI/CD güvenlik kontrol matrisi
| Aşama | Kontrol | Ekipten beklenen kanıt |
|---|---|---|
| Tasarım | Tehdit modelleme ve yetki matrisi | Onaylı kötüye kullanım senaryoları |
| Pull request | Kod inceleme ve statik analiz | İnceleme kaydı ve düzeltme |
| Build | Bağımlılık/SBOM ve gizli anahtar kontrolü | Sürüm envanteri ve tarama özeti |
| Entegrasyon | Negatif yetki ve iş mantığı testleri | Otomatik test sonuçları |
| Staging | Üretim benzeri ayar doğrulaması | Konfigürasyon kontrol listesi |
| Production | Alarm, log ve olay müdahale denemesi | Uyarı takibi ve müdahale kaydı |
Her hat için tek tip geçiş kuralı kullanmak yerine risk derecesine bağlı bir politika oluşturun. İnternete açık, aktif istismar edildiği doğrulanan kritik bir bulgu; yalnızca laboratuvar koşullarında görülebilen düşük etkili bir zafiyetten daha önce giderilebilir. Bu önceliklendirmede CISA’nın KEV kataloğu yardımcıdır.
Geliştirme ekipleri için kontrol listesi
- Kullanıcı/tenant kaynak ayrımı sunucuda doğrulanıyor mu?
- Üretim ortamında debug hata sayfaları ve varsayılan hesaplar kapalı mı?
- Paketler ve container imajları için otomatik zafiyet taraması var mı?
- Gizli anahtarlar repoya yazılmadan saklanıyor mu?
- Parametreli sorgular, çıktı kodlama ve giriş doğrulama uygulanıyor mu?
- Kimlik doğrulama ve oturum çerezleri uygun politikalarla çalışıyor mu?
- Loglarda hassas veri maskeleniyor, kritik olaylara alarm üretiliyor mu?
- Hata ve ağ kesintisi senaryoları test ediliyor mu?
- Yetkili sızma testi ve ASVS tabanlı kontrol için kapsam belgeleniyor mu?
Sık sorulan sorular
OWASP Top 10 tek başına pentest yerine geçer mi?
Hayır. Liste temel riskleri özetler. Yetkili sızma testi, uygulamanın gerçek iş akışını, altyapısını ve entegrasyonlarını da kapsamalıdır.
OWASP Top 10 2026 diye ayrı sürüm var mı?
Bu yazı hazırlanırken web uygulamaları için OWASP’ın yayımlanmış güncel Top 10 sürümü 2025’tir; “2026” burada uygulama ve yayın yılını ifade eder.
ASP.NET Core kullanıyorsam güvende miyim?
Framework güvenli araçlar sunar; ancak yanlış yetkilendirme, güvensiz iş kuralı ve konfigürasyon hatalarını otomatik olarak ortadan kaldırmaz.
OWASP Top 10 taraması otomatik yapılabilir mi?
Bazı teknik zafiyetler ve yanlış yapılandırmalar otomatik araçlarla tespit edilebilir. Ancak iş mantığı, tenant izolasyonu ve kaynak düzeyi yetkilendirme kontrolleri için hem otomatik negatif test hem yetkili manuel değerlendirme gerekir.
OWASP Top 10 2025 neden önceki listeden farklı?
Yazılım tedarik zinciri kategorisi genişletildi ve istisnai durumların yanlış yönetimi ayrı bir risk alanı oldu. Yıllar arasında kategori kodlarını aynı zannetmeden başlıkları güncel sürüm üzerinden takip etmek gerekir.
Her yeni sürümde pentest yaptırmak şart mı?
Kapsam, risk ve sözleşme yükümlülüğüne göre karar verilir. Kritik mimari veya yetki değişikliklerinde hedefli güvenlik testi; sürekli teslim süreçlerinde otomatik kontroller ve periyodik kapsamlı değerlendirme iyi bir bileşim olabilir.
Sonuç: Uygulama güvenliği, kod kalitesinin ayrı bir yan projesi değil, ürünün çalışma biçimidir. OWASP Top 10 ile riskleri sınıflandırın; ASVS gereksinimleri, kod incelemesi ve yetkili testle uygulamanızın gerçek durumunu doğrulayın. AI özellikleri bulunan projelerde RAG ve chatbot güvenliği rehberimiz farklı bir güven katmanına odaklanır. Ancyra’nın yazılım geliştirme ve siber güvenlik çalışmalarına göz atabilirsiniz.
Kaynaklar: OWASP Top 10:2025 · OWASP ASVS 5.0 · OWASP Web Security Testing Guide · CISA KEV kataloğu