OWASP Top 10 Nedir? En Kritik Web Zafiyetleri

Bir web uygulamasını internete açtığınız an, dünyanın her yerinden gelen otomatik tarayıcıların ve saldırganların hedefi haline gelirsiniz. Yıllardır sunucu tarafında çalışan biri olarak size şunu net söyleyebilirim: saldırıların ezici çoğunluğu sıfırıncı gün (zero-day) gibi egzotik açıklardan değil, herkesin bildiği ama düzeltmeye üşendiği klasik hatalardan besleniyor. İşte bu klasik hataların derli toplu bir haritası olması için OWASP Top 10 listesi var. Bu liste, "hangi kapıyı önce kapatmalıyım?" sorusunun kanıta dayalı cevabıdır.

Bu rehberde OWASP Top 10'un ne olduğunu, neden bir sektör standardı haline geldiğini ve listedeki her bir risk kategorisinin gerçek hayatta nasıl istismar edildiğini örneklerle açıklayacağım. Her başlığın sonunda, geliştirici veya sistem yöneticisi olarak hemen uygulayabileceğiniz somut korunma ipuçlarına yer verdim. Amaç akademik bir sınıflandırma ezberletmek değil; bir sonraki dağıtımınızdan (deployment) önce kontrol listenize ekleyebileceğiniz pratik bir güvenlik zihniyeti kazandırmak.

OWASP Top 10 Nedir ve Neden Referans Alınır?#

OWASP (Open Worldwide Application Security Project), uygulama güvenliği alanında çalışan kâr amacı gütmeyen küresel bir topluluktur. Yayımladıkları en bilinen çalışma olan Top 10, web uygulamalarında en yaygın ve en yüksek etkili on güvenlik riskini kategorize eden bir farkındalık belgesidir. Liste yaklaşık üç-dört yılda bir güncellenir; en güncel sürüm gerçek dünyadan toplanan yüz binlerce uygulamanın zafiyet verisine ve saha uzmanlarının anketlerine dayanır. Yani içindeki maddeler tahmin değil, sahadan gelen istatistiktir.

Top 10'un bu kadar çok referans alınmasının nedeni ortak bir dil oluşturmasıdır. Bir denetçi, bir geliştirici ve bir yönetici "A03 Injection açığımız var" dediğinde herkes aynı şeyi anlar. PCI-DSS gibi ödeme kartı standartları, birçok kurumsal tedarikçi sözleşmesi ve devlet ihaleleri güvenlik gereksinimlerini doğrudan OWASP Top 10'a atıfla tanımlar. Ancak bir uyarı: Top 10 bir "her şeyi kapsar" sertifikası değildir. En sık görülen on kategoriyi kapsar, güvenli bir uygulama için gerekli ama tek başına yeterli değildir. Onu bir başlangıç noktası, olgunlaştıkça OWASP ASVS gibi daha kapsamlı standartlara geçmeniz gereken bir ilk basamak olarak görün.

A01 Bozuk Erişim Kontrolü#

Listede uzun süredir bir numarada olan risk budur ve haklı olarak. Bozuk erişim kontrolü, bir kullanıcının kendi yetkisi dışındaki verilere veya işlemlere ulaşabilmesidir. Klasik örnek şudur: /hesap/fatura?id=1043 adresini gören bir kullanıcı, id değerini 1044 yaparak başka birinin faturasını görüntüler. Buna IDOR (Insecure Direct Object Reference) denir. Bir diğer yaygın hata, "sil" veya "yönetici" gibi hassas işlemlerin sunucu tarafında değil sadece arayüzde gizlenmesidir; butonu görmeyen kullanıcı, isteği elle göndererek işlemi yine de tetikleyebilir.

Buradaki temel kural şudur: erişim kararı her zaman sunucu tarafında ve isteği yapan kullanıcının kimliğine göre verilmelidir. İstemciden gelen user_id, role veya is_admin gibi hiçbir alana asla güvenmeyin; bu değeri oturum jetonundan (JWT/session) okuyun. Her sorguyu sahiplik kontrolüyle daraltın.

-- Yanlış: istemcinin gönderdiği id'ye körü körüne güvenmek
SELECT * FROM invoices WHERE id = :requested_id;

-- Doğru: oturumdan gelen kullanıcıya sahiplik zorunluluğu ekle
SELECT * FROM invoices
WHERE id = :requested_id
  AND user_id = :session_user_id;

Rastgele URL'lerin denenmesini zorlaştırmak için sıralı tamsayı yerine tahmin edilemez tanımlayıcılar (UUID veya hashid) kullanmak faydalıdır, ama bunu tek başına güvenlik önlemi sanmayın; asıl korumayı yine sunucudaki sahiplik kontrolü sağlar.

A02 Kriptografik Hatalar#

Eski adıyla "hassas veri ifşası" olan bu kategori, şifreleme yokluğunu veya yanlış uygulanmasını kapsar. En basit ve en sık rastladığım hata, verinin ağ üzerinde düz metin olarak taşınmasıdır. 2026 yılında hâlâ HTTP üzerinden giriş formu sunan site görüyorum; bu, aynı ağdaki herkesin parolayı okuyabilmesi demektir. Diğer klasik hatalar arasında parolaların veritabanında düz metin veya MD5/SHA1 gibi kırılmış algoritmalarla saklanması, sabit kodlanmış (hardcoded) şifreleme anahtarları ve süresi geçmiş TLS sürümleri yer alır.

İlk adım her yerde HTTPS zorunluluğudur. Ücretsiz bir sertifika bile bugün dakikalar içinde kurulabilir; sertifikanın nasıl çalıştığını SSL sertifikası hizmetimiz üzerinden inceleyebilirsiniz. Web sunucusunda HTTP'yi HTTPS'e yönlendirmeyi ve HSTS başlığını unutmayın.

server {
    listen 80;
    server_name ornek.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name ornek.com;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
}

Parolalar için modern, yavaş ve tuzlu (salted) bir algoritma kullanın. Aşağıdaki tablo doğru tercihi özetler.

Şifreleme anahtarlarını asla depoya (repo) commit etmeyin; ortam değişkenlerinde veya bir sır yönetim sisteminde tutun.

A03 Injection#

Injection, uygulamanın kullanıcı girdisini güvenilmez veri olarak değil, çalıştırılacak komutun bir parçası olarak yorumlamasıyla oluşur. En bilineni SQL injection'dır: girdideki tek tırnak, sorgunun mantığını değiştirerek saldırganın tüm veritabanını çekmesine olanak verir. Aynı prensip komut satırı enjeksiyonu, LDAP enjeksiyonu ve tarayıcıda çalışan siteler arası betik çalıştırma (XSS) için de geçerlidir; hepsinin kökeninde "veri ile kod arasındaki sınırın kaybolması" yatar.

SQL injection'a karşı tek gerçek çözüm, parametreli sorgular (prepared statements) kullanmaktır. Girdiyi tırnak içine alıp "temizlemeye" çalışmak kırılgan bir yöntemdir.

-- Tehlikeli: string birleştirme
query = "SELECT * FROM users WHERE email = '" + input + "'"

-- Güvenli: parametreli sorgu (yer tutucu)
SELECT * FROM users WHERE email = ?;
-- input, sürücü tarafından ayrı bir parametre olarak bağlanır

XSS'e karşı ise, kullanıcı içeriğini sayfaya bastığınız her yerde bağlama uygun çıktı kodlaması (output encoding) yapın ve mümkünse Content-Security-Policy başlığıyla satır içi betikleri engelleyin. Girdiyi HTML olarak render etmeniz gerekiyorsa DOMPurify gibi kanıtlanmış bir kütüphaneyle sterbiye edin; asla ham girdiyi doğrudan DOM'a yazmayın. Enjeksiyon denemelerinin büyük kısmını uygulamaya ulaşmadan önce eleyen bir web uygulaması güvenlik duvarı (WAF) da güçlü bir ek katmandır, ancak WAF'ı kod düzeyindeki düzeltmenin yerine değil, üzerine ekleyin.

A04 Güvensiz Tasarım#

Bu kategori, listeye görece yeni eklenen ve zihniyet değişikliği gerektiren bir maddedir. Buradaki mesele bir satır kodun yanlış yazılması değil, iş mantığının en baştan hatalı kurgulanmasıdır. Örneğin "şifremi unuttum" akışında güvenlik sorusunu "annenizin kızlık soyadı" gibi kolayca bulunabilen bir veriye dayandırmak güvensiz bir tasarımdır; kod kusursuz çalışsa bile senaryo sömürülebilir. Bir e-ticaret sitesinde stok kontrolünün ödeme öncesi yerine sonrasında yapılması, ya da bir kupon kodunun kaç kez kullanılabileceğinin hiç sınırlanmaması da tasarım hatalarıdır.

Güvensiz tasarımın panzehiri, geliştirmenin başında tehdit modellemesi yapmaktır. "Bu özelliği kötü niyetli biri nasıl istismar eder?" sorusunu her akış için sorun. Kritik iş kurallarını sunucuda uygulayın, kritik işlemler için hız sınırlaması (rate limiting) ve iş mantığı doğrulamaları ekleyin. Örneğin ödeme, kayıt ve parola sıfırlama uçlarına dakikalık istek sınırı koymak, otomatik kötüye kullanımın önemli bir bölümünü daha kod yazmadan keser. Tasarım kararlarını güvenlik gözüyle gözden geçirmek, sonradan yama yazmaktan çok daha ucuzdur.

A05 Hatalı Güvenlik Yapılandırması#

Yazılım güvenli olabilir ama üzerinde çalıştığı sunucu, çerçeve veya bulut servisi yanlış yapılandırıldığında kapı açık kalır. Bu, sahada en sık gördüğüm kategorilerden biridir çünkü varsayılan ayarlar neredeyse hiçbir zaman güvenli değildir. Açık bırakılmış yönetim panelleri, üretimde açık kalan hata ayıklama (debug) modu, herkese açık bulut depolama kovaları, varsayılan admin/admin parolaları ve sunucu banner'larında sızan sürüm bilgileri hep bu başlığa girer. Saldırganlar bu ayarları taramak için otomatik araçlar kullanır; siz kurduktan bir saat sonra denenmeye başlar.

Korunmanın özü sıkılaştırma (hardening) ve tekrarlanabilirliktir. Kullanmadığınız her modülü, portu ve varsayılan hesabı kapatın. Üretimde ayrıntılı hata mesajlarını gizleyin, güvenlik başlıklarını (CSP, X-Content-Type-Options, X-Frame-Options) ekleyin.

# Uygulama ortamı için asgari sıkılaştırma kontrol listesi
production:
  debug: false            # üretimde asla true olmasın
  directory_listing: off  # dizin listeleme kapalı
  default_credentials: rotated  # varsayılan parolalar değiştirildi
  admin_panel: ip_restricted    # yönetim paneli IP kısıtlı
  error_detail: generic         # kullanıcıya jenerik hata
  security_headers: enabled

Yapılandırmayı elle sunucu sunucu ayarlamak yerine betiklerle veya altyapı-kod (IaC) araçlarıyla standartlaştırın; böylece her yeni sunucu aynı güvenli tabana sahip olur. Bu tür sürekli yapılandırma ve güncelleme yükünü tek başınıza taşımak istemiyorsanız sunucu yönetimi hizmetimiz bu sıkılaştırmayı sizin adınıza üstlenir.

A06 A07 ve A08 Bileşenler Kimlik Doğrulama ve Bütünlük#

Üç kategoriyi birlikte ele alalım çünkü modern uygulamaların çoğunda birbirine bağlıdırlar. A06 Güncel Olmayan Bileşenler, projelerinizin bağımlı olduğu kütüphane, çerçeve ve sunucu yazılımlarının bilinen açıklı sürümlerde kalmasıdır. Ünlü ihlallerin çoğu, yamalanmamış tek bir kütüphaneden başlar. Çözüm, bağımlılıklarınızı envanterleyip düzenli olarak taramaktır.

# Node.js projelerinde bilinen açıkları tara
npm audit --production

# Sistem paketlerini güncel tut (Debian/Ubuntu)
sudo apt update && sudo apt upgrade -y

A07 Kimlik Doğrulama Hataları, zayıf parola politikaları, oturum jetonlarının sızması, kaba kuvvet (brute force) saldırılarına açık giriş uçları ve eksik çok faktörlü doğrulama gibi sorunları kapsar. Girişe hız sınırı ve hesap kilitleme ekleyin, oturum jetonlarını her giriş sonrası yenileyin ve mutlaka çok faktörlü kimlik doğrulama (2FA) sunun. A08 Yazılım ve Veri Bütünlüğü Hataları ise güvenilmez kaynaklardan gelen kod veya güncellemelerin doğrulanmadan çalıştırılmasıyla ilgilidir; imzasız güncelleme mekanizmaları ve CI/CD hattına sızma bu başlığa girer. Bağımlılıkları yalnızca güvenilir kayıtlardan çekin, mümkünse bütünlük özetleriyle (integrity hash) sabitleyin ve derleme hattınıza erişimi sıkı tutun.

A09 ve A10 Loglama Eksikliği ve SSRF#

A09 Güvenlik Loglama ve İzleme Eksikliği doğrudan bir açık değildir; asıl tehlike, bir saldırının fark edilmeden aylarca sürmesidir. Kayıt tutmayan bir sistemde ihlal genellikle üçüncü bir taraf haber verene kadar anlaşılmaz. Başarısız giriş denemelerini, yetki hatalarını ve kritik işlemleri anlamlı biçimde loglayın; bu logları merkezî ve değiştirilemez bir yerde saklayın. Önemli olan yalnızca kayıt tutmak değil, o kayıtlar üzerinde alarm kurmaktır: aynı IP'den ard arda gelen yüzlerce başarısız giriş bir uyarı tetiklemeli.

A10 Sunucu Taraflı İstek Sahteciliği (SSRF), uygulamanın kullanıcıdan aldığı bir URL'ye sunucu adına istek yapmasıyla oluşur. Saldırgan bu URL'yi http://169.254.169.254 gibi iç bulut meta veri adreslerine veya iç ağdaki servislere yönlendirerek, dışarıdan erişemeyeceği kaynaklara sunucunun ayrıcalıklarıyla ulaşır. Korunmak için kullanıcıdan gelen adresleri bir izin listesiyle (allowlist) doğrulayın, çözümlenen IP'nin özel/loopback aralıklarında olmadığını kontrol edin ve yönlendirmeleri kapatın.

# SSRF savunmasının çekirdeği: hedef IP'yi çöz ve özel aralıkları reddet
# 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8,
# 169.254.0.0/16 (link-local) adreslerine giden istekleri engelle

Bu iki madde, "önlemek kadar fark etmek de önemlidir" ilkesinin somut karşılığıdır. İyi bir loglama, diğer dokuz maddeye rağmen içeri sızan bir saldırganı yakalamanızı sağlayan son güvenlik ağınızdır.

Katmanlı Savunma ile Riski Nasıl Azaltırsınız?#

OWASP Top 10'a tek tek baktığımızda ortak bir ders çıkar: hiçbir madde tek bir sihirli çözümle kapanmaz; güvenlik katmanlı olmak zorundadır. Kodun güvenli yazılması ilk katmandır, ama üzerine yapılandırma sıkılaştırması, bir WAF, düzenli yedekleme ve izleme eklendiğinde tek bir katmandaki hatanın tüm sistemi düşürme ihtimali ciddi biçimde azalır. Buna "derinlemesine savunma" denir.

Pratik bir kontrol listesi olarak şunları düzenli döngüye alın: bağımlılıkları haftalık tarayın, üretim öncesi bir güvenlik gözden geçirmesi yapın, günlük otomatik yedekleme alın ki bir ihlal veya fidye yazılımı durumunda temiz bir noktaya dönebilesiniz, ve bir saldırı yüzeyi analizinden geçin. WordPress kullanıyorsanız platforma özgü sıkılaştırmalar için WordPress güvenliği rehberimizi inceleyin; genel filtreleme katmanının nasıl çalıştığını ise WAF makalemizde bulabilirsiniz. Barındırma tarafında güncel PHP sürümü, izole hesaplar ve otomatik güvenlik yamaları sunan bir altyapı seçmek, listenin birçok maddesini sizin adınıza kapatır; bu altyapıyı hosting paketlerimizde hazır bulabilirsiniz.

Sıkça Sorulan Sorular#

OWASP Top 10 bir güvenlik standardı mıdır?#

Hayır, teknik olarak bir standart değil bir farkındalık belgesidir. En yaygın on web güvenlik riskini öncelik sırasıyla listeler ve ortak bir dil sağlar. Ancak PCI-DSS gibi gerçek standartlar ve birçok denetim çerçevesi gereksinimlerini OWASP Top 10'a atıfla tanımladığı için pratikte bir uyum ölçütü gibi kullanılır. Kapsamlı bir güvenlik doğrulaması için OWASP'ın ASVS belgesine geçmeniz gerekir.

OWASP Top 10 ne sıklıkla güncelleniyor?#

Liste yaklaşık üç ila dört yılda bir güncellenir ve her sürüm gerçek dünyadan toplanan zafiyet verisiyle sektör anketlerinin birleşimine dayanır. Güncellemelerde bazı kategoriler birleşir, isim değiştirir veya sıralaması değişir; örneğin "güvensiz tasarım" görece yeni bir eklemedir. Bu yüzden her zaman en güncel sürüme atıf yapmak ve kategori numaralarını değil kavramları takip etmek en sağlıklısıdır.

En sık istismar edilen zafiyet hangisidir?#

Sahada en sık karşılaşılan iki kategori bozuk erişim kontrolü ve injection'dır. Bozuk erişim kontrolü, kullanıcının yetkisi dışındaki verilere ulaşmasına izin verdiği için son listelerde ilk sıradadır. Injection ise onlarca yıldır varlığını sürdüren klasik bir tehdittir. İkisi de çoğunlukla temel geliştirme disiplinleriyle (sunucu tarafı yetki kontrolü ve parametreli sorgular) önlenebilir olması açısından dikkat çekicidir.

Küçük bir web sitesi için de OWASP Top 10 önemli mi?#

Kesinlikle evet. Saldırıların büyük çoğunluğu belirli bir siteyi hedef almaz; internet genelini tarayan otomatik botlar tarafından yapılır ve bu botlar sitenizin büyüklüğüne bakmaz. Küçük bir tanıtım sitesi bile, ele geçirildiğinde kötü amaçlı yazılım dağıtmak veya spam göndermek için kullanılabilir. Listedeki temel önlemler, projenin ölçeğinden bağımsız olarak her uygulama için geçerlidir.

WAF kullanmak OWASP Top 10 açıklarını tamamen kapatır mı?#

Hayır, WAF çok değerli bir katmandır ama kod düzeyindeki kusurun yerine geçmez. Bir web uygulaması güvenlik duvarı, injection ve XSS gibi bilinen saldırı desenlerinin önemli bir bölümünü uygulamaya ulaşmadan filtreler ve size yama yapmak için zaman kazandırır. Ancak iş mantığı hataları, bozuk erişim kontrolü ve güvensiz tasarım gibi maddeler yalnızca uygulamanın kendi kodunda düzeltilebilir. WAF'ı güvenli kodlamanın üzerine eklenen bir katman olarak konumlandırın.

Geliştirici olarak nereden başlamalıyım?#

En yüksek etkili iki alışkanlıkla başlayın: her veri erişiminde sunucu tarafında sahiplik/yetki kontrolü yapmak ve tüm veritabanı sorgularını parametreli hale getirmek. Bu ikisi, listenin en sık istismar edilen maddelerini büyük ölçüde kapatır. Ardından bağımlılık taramasını (npm audit gibi), her yerde HTTPS'i ve temel güvenlik başlıklarını sürecinize ekleyin. Güvenliği sona bırakılan bir görev değil, her özelliğin doğal bir parçası olarak görmek en kalıcı çözümdür.

Kapanış#

OWASP Top 10, web güvenliğinin tamamı değildir ama sağlam bir başlangıç noktasıdır. Listedeki on maddeyi bir kontrol listesi gibi ele alıp erişim kontrolünü sunucuya taşır, sorgularınızı parametreleştirir, her yerde HTTPS zorlar ve bağımlılıklarınızı güncel tutarsanız, gerçek dünyadaki saldırıların büyük bölümünü daha ilk kapıda durdurmuş olursunuz. Güvenlik tek seferlik bir iş değil, her dağıtımda tekrarlanan bir disiplindir.

Clou.TR olarak bu yükün önemli bir kısmını altyapı tarafında sizin adınıza taşıyoruz. Güncel yazılım sürümleri ve sıkılaştırılmış sunucularla gelen hosting paketlerimizi, saldırı trafiğini kaynağında eleyen WAF çözümümüzü, ücretsiz SSL sertifikalarımızı ve olası bir ihlalde temiz bir noktaya dönmenizi sağlayan otomatik yedekleme hizmetimizi bir arada değerlendirebilirsiniz. Kendi sunucunuzu yönetiyor ama sıkılaştırma yükünü paylaşmak istiyorsanız sunucu yönetimi hizmetimize göz atın. Uygulamanızı bugün bu ilkelerle gözden geçirmeye başlayın; güvenlik, en ucuz olduğu an daima "şimdi"dir.