OWASP Top 10:2025 listesinin tamamını ezberlemek gerekmez; bir öğrenci web projesini teslim etmeden önce yalnızca beş temel alanı kontrol etmek çoğu durumda yeterlidir: erişim kontrolü, yapılandırma, bağımlılıklar, girdi işleme ve hata durumları. Bu beş alan, gerçek dünyadaki güvenlik açıklarının büyük kısmının kaynağıdır ve küçük ölçekli bir proje için pratik bir güvenlik ağı oluşturur.
Bu makalede listenin tamamıyla uğraşmak yerine, teslim öncesi hızlıca uygulayabileceğiniz somut bir kontrol listesi bulacaksınız. Amaç, güvenlik uzmanı olmak değil; hocanızın veya jürinin ilk bakışta fark edeceği temel hataları önceden kapatmak.
Neden Tüm Listeyle Uğraşmaya Değmez
OWASP Top 10, öncelikle kurumsal ölçekte, üretimde çalışan ve gerçek kullanıcı verisi barındıran sistemler için hazırlanmış bir öncelik listesidir. Büyük bir e-ticaret platformu ile bir dönem sonu ödevi olarak yazılan not takip API'si aynı risk profiline sahip değildir. Listedeki her madde, öğrenci projesi bağlamında aynı ağırlığı taşımaz.
Örneğin, karmaşık tedarik zinciri saldırıları veya büyük ölçekli günlükleme altyapısı eksiklikleri, tek kişilik bir okul projesinde pratikte çok düşük olasılıklı risklerdir. Buna karşılık, aşağıdaki beş alan neredeyse her öğrenci projesinde gerçek ve kolayca test edilebilir hatalara yol açar:
- Erişim kontrolü: Bir kullanıcının başka bir kullanıcının verisine erişip erişemediği.
- Yapılandırma: Varsayılan şifreler, açık hata mesajları, gereksiz açık portlar.
- Bağımlılıklar: Güncel olmayan veya bilinen açığı olan kütüphaneler.
- Girdi işleme: Kullanıcıdan gelen verinin doğrulanmadan veritabanına veya ekrana yansıması.
- Hata durumları: Beklenmeyen girdilerde uygulamanın çökmesi veya iç detayları sızdırması.
Bu beş alana odaklanmak, kalan zamanınızı gerçek işlevsellik geliştirmeye ayırmanızı sağlarken, teslim sırasında en sık karşılaşılan güvenlik eleştirilerinin önüne geçer.
``` Not: Yukarıdaki beş madde isimlendirmesi (erişim kontrolü, yapılandırma, bağımlılıklar, girdi işleme, hata durumları) OWASP'ın resmi madde başlıklarını birebir alıntılamadan, genel kavram olarak kullanıldı; bu şekilde doğrulanmamış "2025" madde adlarını gerçekmiş gibi sunma riskini taşımıyor.
Önceki ve sonraki parçalarla bağlantısını sen kurduğun için, bu parçayı doğrudan bahsedilen iki bölümle veriyorum:
---
Somut örnek: Not takip API'si
Teoriyi bir kenara koyup küçük bir örnek üzerinden gidelim: öğrencilerin ders notlarını tuttuğu basit bir REST API. GET /notes/:id endpoint'i bir öğrencinin notunu döndürüyor. Proje "çalışıyor" çünkü giriş yapan kullanıcı kendi notunu görebiliyor. Ama id parametresini değiştirip başka bir öğrencinin kaydına erişmeyi kimse test etmemiş. Bu, OWASP Top 10:2025'teki erişim kontrolü zafiyetlerinin klasik örneği: yetkilendirme sadece arayüzde var, sunucu tarafında kontrol edilmiyor.
Çözüm karmaşık değil: her istekte, oturumdaki kullanıcı kimliği ile kaydın sahibi karşılaştırılmalı. Eşleşmiyorsa 403 (yasak) veya 404 (bulunamadı) döndürülmeli; hangisini seçeceğiniz kullandığınız framework'ün ve projenizin gizlilik gereksinimlerine bağlı, ama önemli olan sunucunun bu kontrolü gerçekten yapması.
İkinci senaryo: bir hata oluştuğunda API, veritabanı sorgusunun tamamını veya framework'ün stack trace'ini kullanıcıya döndürüyor. Bu, hata yönetimi ve bilgi sızıntısı başlığına giriyor. Geliştirme ortamında faydalı olan bu detaylar, teslim edilen üründe saldırgana veritabanı yapısı hakkında bedava bilgi verir. Çözüm: kullanıcıya genel bir hata mesajı, loglara ise detaylı bilgi.
Üçüncü senaryo: package.json veya requirements.txt dosyasındaki bağımlılıklardan biri, bilinen bir güvenlik açığına sahip eski bir sürüm. Bunu elle taramak yerine npm audit (Node.js projeleri için) veya pip-audit (Python projeleri için) gibi araçları çalıştırmak yeterli; ikisi de güncel ve yaygın kullanılan araçlar. Çıkan uyarıları görmezden gelmek yerine, en azından "kritik" ve "yüksek" seviyeli olanları güncellemek, savunmasız ve güncel bileşenler maddesini büyük ölçüde kapatır.
Teslim öncesi 8 soruluk kontrol listesi
Bu liste OWASP'ın resmi bir dokümanı değil, yukarıdaki örneklerden ve yaygın öğrenci projesi hatalarından türetilmiş pratik bir özet. Teslimden önce şu sekiz soruyu kendinize sorun:
- Bir kullanıcı, URL veya parametre değiştirerek başkasının verisine erişebiliyor mu?
- Şifreler ve token'lar veritabanında düz metin olarak mı duruyor?
- Hata mesajları son kullanıcıya teknik detay (stack trace, SQL sorgusu) sızdırıyor mu?
npm auditveyapip-auditçalıştırdınız mı, kritik uyarı var mı?- Kullanıcı girdisi doğrudan veritabanı sorgusuna ya da komut satırına ekleniyor mu?
- API anahtarları veya veritabanı şifreleri kod içinde mi, yoksa ortam değişkeninde mi?
- Giriş yapmamış bir kullanıcı, giriş gerektiren bir endpoint'e erişebiliyor mu?
- Loglar hassas veri (şifre, kredi kartı) içeriyor mu?
Bu sorulara "evet, açık var" diye cevap verdiğiniz her madde, teslimden önce düzeltilmesi gereken bir bulgudur.
Bu kontrol listesi ne değildir
Burada bir şeyi açıkça söylemek gerekiyor: sekiz soruluk bu liste bir güvenlik garantisi değil. "Bu kontrol listesini geçtim, demek ki projem güvenli" gibi bir sonuca varmak yanlış olur. Liste, öğrenci projelerinde en sık rastlanan ve en kolay gözden kaçan hataları yakalamak için tasarlandı, yoksa OWASP Top 10'un kapsadığı risklerin tamamını değerlendirmiyor.
Gerçek bir güvenlik değerlendirmesi çok daha derin bir süreç gerektirir. Kod incelemesi (code review) satır satır mantık hatalarını, yetkilendirme kontrollerinin nerede eksik kaldığını, hata yönetiminin bilgi sızdırıp sızdırmadığını ortaya çıkarır. Tehdit modelleme ise "bu sistemi kim, neden ve nasıl kötüye kullanabilir" sorusunu sistematik olarak sorar; bu, tek bir kontrol listesiyle asla yakalanamayacak senaryoları gündeme getirir. Bağımlılık taraması, sızma testi, otomatik güvenlik tarayıcıları gibi araçlar da bu sürecin parçalarıdır ve öğrenci projesi ölçeğini aşan bir emek ister.
Dolayısıyla bu listeyi bir başlangıç filtresi olarak görmek en doğrusu. Projenizi teslim etmeden önce en temel hataları elemenize yardımcı olur, ama "production'a hazır" ya da "güvenlik açısından onaylandı" anlamına gelmez. Gerçek dünyada çalışan bir sistem kurmayı hedefliyorsanız, bu sekiz soru sizin için sadece ilk adım olmalı.
Kapanış / Yönlendirme
OWASP Top 10, güvenliği bir defalık kontrol listesi olarak değil, geliştirme sürecinin doğal bir parçası olarak görmeyi öğretir. Öğrenci projenizde bu sekiz soruyu alışkanlık haline getirdiğinizde, ileride karşılaşacağınız daha karmaşık sistemlerde de aynı refleksle hareket edersiniz.
Konuyu daha sistematik öğrenmek isterseniz [genel eğitim sayfamızda] OWASP Top 10'un her maddesini ayrı ayrı ele aldığımız içerikleri bulabilirsiniz. Projenize özel bir değerlendirme veya birebir yönlendirme almak isterseniz [özel ders sayfamıza] göz atabilirsiniz.
Güvenlik, bir kerede öğrenilip kapatılan bir konu değil. Küçük adımlarla, her projede biraz daha bilinçli kararlar vererek ilerlemek, uzun vadede en sağlam yöntem.
