Web uygulamaları artık işletmelerin yalnızca dijital vitrini değil; gelirin, müşteri verisinin ve günlük operasyonların merkezinde duran kritik altyapılardır. Bu merkezîlik, aynı zamanda saldırganlar için son derece çekici bir hedef anlamına gelir. Bir e-ticaret sitesindeki tek bir erişim kontrolü açığı on binlerce müşterinin kişisel verisinin sızmasına; bir kurumsal portaldaki enjeksiyon zafiyeti ise tüm veritabanının ele geçirilmesine yol açabilir. Türkiye'de KVKK yükümlülükleri ve artan siber tehdit yoğunluğu düşünüldüğünde, web güvenliği artık "ileride bakarız" denecek bir konu olmaktan çıkmıştır.

İşte tam bu noktada OWASP Top 10 devreye girer. OWASP (Open Worldwide Application Security Project), web uygulama güvenliği alanında dünyanın en saygın ve bağımsız topluluklarından biridir. Yayımladığı OWASP Top 10 listesi, gerçek üretim ortamlarından toplanan veriler ışığında en yaygın ve en kritik on güvenlik riskini sıralar. Bu rehberde KaliteliWebsite olarak, İstanbul merkezli bir yazılım ajansı kimliğiyle bu on kategorinin her birini somut örneklerle, gerçek kod parçalarıyla ve uygulanabilir önlemlerle ele alıyoruz. Amacımız size soyut bir korku listesi değil, ekibinizin yarın sabah uygulamaya başlayabileceği mühendislik temelli bir savunma çerçevesi sunmak.

Güvenlik açıklarını analiz eden bir siber güvenlik ekibi

OWASP Top 10 nedir ve neden önemlidir?

OWASP Top 10, web uygulamalarında en sık karşılaşılan ve en ciddi etki yaratan on güvenlik riskini belgeleyen, düzenli olarak güncellenen bir farkındalık dokümanıdır. Liste tahmine değil veriye dayanır: yüz binlerce uygulamadan toplanan zafiyet istatistikleri, güvenlik araştırmacılarının anketleri ve gerçek olay raporları analiz edilerek oluşturulur. Bu yüzden liste, "teorik olarak mümkün olan" değil, "pratikte gerçekten istismar edilen" riskleri yansıtır.

Listenin değeri yalnızca bir kontrol listesi olmasında değil, ortak bir dil oluşturmasındadır. Bir geliştirici "bu uçnokta A01'e açık" dediğinde, ekibin tamamı bunun bir erişim kontrolü sorunu olduğunu anında anlar. Bu ortak dil, güvenlik tartışmalarını netleştirir ve önceliklendirmeyi kolaylaştırır. Güncel sürüm on kategoriyi şu kodlarla tanımlar: A01 Bozuk Erişim Kontrolü, A02 Kriptografik Hatalar, A03 Enjeksiyon, A04 Güvensiz Tasarım, A05 Hatalı Güvenlik Yapılandırması, A06 Güncel Olmayan ve Zafiyetli Bileşenler, A07 Kimlik Doğrulama Hataları, A08 Yazılım ve Veri Bütünlüğü Hataları, A09 Güvenlik Günlükleme ve İzleme Hataları, A10 Sunucu Tarafı İstek Sahteciliği (SSRF).

Önemli bir uyarı: OWASP Top 10 bir bitiş çizgisi değil, başlangıç noktasıdır. Bu on kategoriyi kapatmak, uygulamanızın mükemmel güvenli olduğu anlamına gelmez; yalnızca en yaygın hataların büyük çoğunluğunu elediğiniz anlamına gelir. Gerçek güvenlik, bu temeli sürekli bir güvenli geliştirme kültürüyle desteklemekle mümkün olur.

OWASP Top 10 listesine hızlı bakış: açık ve önlem tablosu

Detaylı incelemeye geçmeden önce, on kategorinin tamamını bir bakışta gösteren özet bir tablo faydalı olacaktır. Aşağıdaki tablo her riski, tipik bir örneğini ve uygulanabilir birincil önlemini özetler:

Kod	Risk	Tipik örnek	Birincil önlem
A01	Bozuk Erişim Kontrolü	Kullanıcının başkasının siparişini URL'deki id'yi değiştirerek görmesi	Sunucu tarafında her istekte yetki doğrulama
A02	Kriptografik Hatalar	Parolaların düz metin veya zayıf hash ile saklanması	TLS, güçlü hash (bcrypt/argon2), anahtar yönetimi
A03	Enjeksiyon	SQL injection, XSS, komut enjeksiyonu	Parametreli sorgu, çıktı kodlama, girdi doğrulama
A04	Güvensiz Tasarım	İş mantığında oran sınırı ve doğrulama eksikliği	Tehdit modelleme, güvenli tasarım desenleri
A05	Hatalı Yapılandırma	Açık hata mesajları, eksik güvenlik başlıkları	Sıkılaştırma, güvenlik başlıkları, varsayılanları kapatma
A06	Zafiyetli Bileşenler	Bilinen açığı olan eski kütüphane sürümü	Bağımlılık tarama, düzenli güncelleme
A07	Kimlik Doğrulama Hataları	Zayıf parola politikası, kaba kuvvet koruması yokluğu	MFA, oran sınırı, güvenli oturum yönetimi
A08	Bütünlük Hataları	İmzasız güncelleme, güvensiz deserializasyon	İmza doğrulama, güvenilir kaynak, CI/CD sertleştirme
A09	İzleme Hataları	Saldırı tespit edilmeden haftalarca devam etmesi	Merkezî günlükleme, alarm, izlenebilirlik
A10	SSRF	Sunucunun iç ağdaki servislere zorla istek atması	URL beyaz liste, ağ segmentasyonu, metadata erişimi kısıtlama

Bu tablo bir yol haritası gibi kullanılabilir: ekibiniz her satırı tek tek ele alıp uygulamanızda ilgili kontrolün var olup olmadığını işaretleyebilir. Şimdi kategorileri gruplar hâlinde derinlemesine inceleyelim.

A01-A03: En kritik üç kategori

Listenin ilk üç sırası, hem en sık karşılaşılan hem de istismar edildiğinde en yıkıcı sonuçlar doğuran kategorilerdir. Projelerimizde güvenlik denetimine bu üçüyle başlamayı öneriyoruz.

A01 Bozuk Erişim Kontrolü

Erişim kontrolü, bir kullanıcının yalnızca yetkili olduğu kaynaklara ulaşabilmesini sağlayan mekanizmadır. Bu kontrol bozulduğunda, sıradan bir kullanıcı başka kullanıcıların verisine veya yönetici işlevlerine erişebilir. En klasik örnek, doğrudan nesne referansı (IDOR) zafiyetidir: bir kullanıcı kendi siparişini görüntülerken URL'deki sipariş numarasını değiştirerek başkasının siparişine ulaşabiliyorsa, uygulamanın erişim kontrolü bozuktur.

Buradaki kritik kural şudur: yetki kontrolü asla yalnızca istemci tarafında yapılmamalıdır. Arayüzde bir düğmeyi gizlemek güvenlik değildir; saldırgan isteği doğrudan API'ye gönderebilir. Doğru yaklaşım, her isteğin sunucuda, o kaynağa erişen kişinin gerçekten yetkili olup olmadığını sorgulamasıdır:

// Hatalı: yalnızca kaydı getirir, sahipliği kontrol etmez
app.get('/api/siparis/:id', async (req, res) => {
  const siparis = await Siparis.findById(req.params.id)
  res.json(siparis)
})

// Doğru: kaydın isteyen kullanıcıya ait olduğunu doğrular
app.get('/api/siparis/:id', kimlikDogrula, async (req, res) => {
  const siparis = await Siparis.findById(req.params.id)
  if (!siparis || siparis.kullaniciId !== req.kullanici.id) {
    return res.status(404).json({ hata: 'Bulunamadi' })
  }
  res.json(siparis)
})

Yetkisiz erişimde 403 yerine 404 dönmek de bilinçli bir tercihtir; böylece saldırgana kaynağın var olup olmadığı bilgisini sızdırmazsınız. En küçük ayrıcalık ilkesini (principle of least privilege) benimsemek, varsayılan olarak her şeyi reddedip yalnızca açıkça izin verileni açmak, bu kategorideki riskleri büyük ölçüde kapatır.

A02 Kriptografik Hatalar

Bu kategori, hassas verinin hem aktarım sırasında hem de saklandığında yeterince korunmamasını kapsar. En sık görülen hatalar; parolaların düz metin saklanması, MD5 veya SHA-1 gibi kırılmış algoritmalarla hashlenmesi, TLS kullanılmaması ve şifreleme anahtarlarının kaynak koduna gömülmesidir.

Parola saklamada doğru yöntem, özel olarak bu iş için tasarlanmış, yavaş ve tuzlamalı (salted) hash algoritmaları kullanmaktır. bcrypt, scrypt veya argon2 bu amaç için uygundur:

import bcrypt from 'bcrypt'

// Kayıt sırasında
const hash = await bcrypt.hash(duzMetinParola, 12)

// Giriş sırasında
const dogruMu = await bcrypt.compare(girilenParola, hash)

Aktarım güvenliği için tüm trafik HTTPS üzerinden taşınmalı, HSTS başlığı ile tarayıcının yalnızca güvenli bağlantı kurması zorlanmalıdır. Şifreleme anahtarları ise asla depoya işlenmemeli; ortam değişkenlerinde veya özel bir gizli anahtar yöneticisinde tutulmalıdır. Hassas verinin yalnızca gerçekten gerektiğinde toplanması da güçlü bir önlemdir: saklamadığınız veriyi kimse çalamaz.

A03 Enjeksiyon

Enjeksiyon, kullanıcıdan gelen güvenilmeyen verinin bir yorumlayıcıya komut olarak gönderilmesiyle oluşur. SQL injection, NoSQL injection, komut enjeksiyonu ve XSS bu ailenin üyeleridir. Klasik SQL injection örneği, kullanıcı girdisini doğrudan sorguya yapıştırmaktan doğar:

// Tehlikeli: girdi doğrudan sorguya gömülüyor
const sorgu = "SELECT * FROM kullanicilar WHERE eposta = '" + eposta + "'"

// Güvenli: parametreli sorgu
const sonuc = await db.query(
  'SELECT * FROM kullanicilar WHERE eposta = $1',
  [eposta]
)

İlk örnekte saldırgan eposta alanına özel karakterler enjekte ederek sorgunun mantığını değiştirebilir; ikinci örnekte ise girdi her zaman veri olarak ele alınır, asla komut olarak yorumlanmaz. Enjeksiyona karşı temel savunma katmanları şunlardır:

Parametreli sorgu ve hazır ifadeler (prepared statements) kullanmak.
ORM kullanırken ham sorgu birleştirmekten kaçınmak.
Girdiyi beklenen tipe, uzunluğa ve formata göre doğrulamak (allowlist mantığı).
Çıktıyı bağlamına uygun biçimde kodlamak; özellikle XSS için HTML, JavaScript ve URL bağlamlarında ayrı kodlama uygulamak.

Enjeksiyon ailesinin en yaygın iki üyesi olan XSS ve SQL injection'ı ileride ayrı bir başlıkta daha ayrıntılı ele alacağız.

A04-A06: Tasarım, yapılandırma ve bileşen riskleri

Bu üç kategori, tek bir kod satırından çok mimari kararlar, sistem yapılandırması ve bağımlılık yönetimiyle ilgilidir. Çoğu zaman gözden kaçarlar çünkü "çalışan" bir uygulamada görünür bir hata yaratmazlar.

A04 Güvensiz Tasarım

Güvensiz tasarım, kusurlu kodlama değil, kusurlu mimari demektir. En iyi yazılmış kod bile temelde güvensiz bir tasarımı kurtaramaz. Örneğin parola sıfırlama akışını yalnızca telefon numarasının son dört hanesiyle doğrulayan bir sistem, kodu kusursuz olsa bile tasarımı gereği güvensizdir. Bu kategoriye karşı en güçlü silah tehdit modellemedir: bir özelliği geliştirmeden önce "bunu kim, neden ve nasıl kötüye kullanır?" sorusunu sistematik olarak sormak.

Güvenli tasarım; oran sınırlama, iş mantığı doğrulaması, çok adımlı işlemlerde durum kontrolü ve varsayılan güvenli davranış gibi desenleri proje başında planlamayı gerektirir. Güvenliği sonradan eklenen bir yama olarak değil, tasarımın bir bileşeni olarak ele almak şarttır.

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

Bu kategori, doğru yazılmış bir uygulamanın yanlış yapılandırılmasından doğar. Açık bırakılmış yönetim panelleri, üretimde aktif kalmış hata ayıklama modu, kullanıcıya tüm yığın izini (stack trace) gösteren hata mesajları, değiştirilmemiş varsayılan parolalar ve eksik güvenlik başlıkları bu sınıfa girer. Saldırgana sızdırdığınız her teknik detay, ona bir sonraki adımı kolaylaştırır.

Güvenlik başlıkları bu alanda en yüksek getirili önlemlerden biridir. Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security ve Referrer-Policy gibi başlıklar birçok saldırı sınıfını tek bir yapılandırmayla zorlaştırır. Bu konuyu uçtan uca işlediğimiz web güvenliği başlıkları rehberimizde her başlığın ne işe yaradığını ve nasıl yapılandırılacağını ayrıntılı bulabilirsiniz. Temel kural nettir: üretime çıkmadan önce her ortamı sıkılaştırın, gereksiz servisleri kapatın ve varsayılanlara asla güvenmeyin.

A06 Güncel Olmayan ve Zafiyetli Bileşenler

Modern bir web uygulaması yüzlerce, bazen binlerce üçüncü taraf bağımlılık içerir. Bu bağımlılıklardan herhangi birinde bilinen bir açık varsa, sizin kodunuz kusursuz olsa bile uygulamanız savunmasızdır. Geçmişte yaşanan büyük çaplı veri ihlallerinin önemli bir kısmı, güncellenmemiş tek bir kütüphaneden kaynaklanmıştır.

Bu riski yönetmenin yolu, bağımlılık güvenliğini otomatik ve sürekli bir sürece dönüştürmektir:

Bağımlılık tarama araçlarını (npm audit, Dependabot, Snyk benzeri çözümler) CI/CD hattınıza entegre edin.
Kullanmadığınız bağımlılıkları kaldırarak saldırı yüzeyini küçültün.
Bileşenleri yalnızca resmî ve güvenilir kaynaklardan alın.
Güncellemeleri rastgele değil, planlı ve test edilebilir bir takvimle uygulayın.

Bağımlılık güncellemelerini düzenli yürütmek, çoğu işletmenin tek başına sürdürmekte zorlandığı bir iştir. Bakım, izleme ve destek hizmetimiz kapsamında tam olarak bu süreci üstleniyor; uygulamanızın bağımlılıklarını sürekli izleyip kritik açıkları siz fark etmeden kapatıyoruz.

A07-A10: Kimlik, bütünlük, izleme ve SSRF

Son dört kategori, uygulamanın kimini içeri aldığından, kodun ve verinin bütünlüğünden, olup biteni görebilme yeteneğinden ve sunucunun kandırılarak istek atmasından oluşur.

A07 Kimlik Doğrulama Hataları

Kimlik doğrulama, kullanıcının iddia ettiği kişi olduğunu kanıtlama sürecidir; bu süreçteki zayıflıklar hesapların ele geçirilmesine yol açar. Zayıf parola politikaları, kaba kuvvet (brute force) saldırılarına karşı koruma yokluğu, güvensiz oturum yönetimi ve oturum kimliklerinin tahmin edilebilir olması başlıca sorunlardır. Önlem paketi şunları içerir: çok faktörlü kimlik doğrulama (MFA), başarısız giriş denemelerine oran sınırı ve hesap kilitleme, güçlü ve yenilenebilir oturum belirteçleri, oturum süresinin makul tutulması.

JWT (JSON Web Token) tabanlı kimlik doğrulamada da sık hatalar görülür: belirteçlerin çok uzun ömürlü olması, imza algoritmasının doğrulanmaması veya gizli anahtarın zayıf olması. JWT'yi kısa ömürlü erişim belirteci ile yenileme belirteci (refresh token) ikilisi olarak kurgulamak, ele geçirilme penceresini ciddi şekilde daraltır. API tarafında kimlik doğrulamanın nasıl güvenli kurulacağını API güvenliği en iyi pratikleri yazımızda ayrıntılı ele aldık.

A08 Yazılım ve Veri Bütünlüğü Hataları

Bu kategori, koda ve veriye güvenirken bütünlüğünü doğrulamamaktan doğar. Örnekleri arasında imzası doğrulanmayan yazılım güncellemeleri, güvensiz deserializasyon ve güvenilmeyen bir kaynaktan çekilen yapı (build) bileşenleri yer alır. Saldırgan, güncelleme mekanizmasına veya CI/CD hattınıza sızabilirse, kullanıcılarınıza kötü amaçlı kod dağıtabilir. Önlem olarak; bileşenlerin dijital imzalarını doğrulamak, yalnızca güvenilir paket depolarını kullanmak ve CI/CD ortamını en küçük ayrıcalık ilkesiyle sertleştirmek gerekir.

A09 Güvenlik Günlükleme ve İzleme Hataları

Bir saldırıyı önleyemeseniz bile en azından gerçekleştiğini görebilmelisiniz. Yetersiz günlükleme ve izleme, ihlallerin haftalarca, bazen aylarca fark edilmeden sürmesinin başlıca nedenidir. Başarısız giriş denemeleri, yetkilendirme hataları ve kritik işlemler merkezî olarak günlüklenmeli; bu günlükler anlamlı alarmlara bağlanmalıdır. Aynı zamanda günlüklere parola, belirteç veya kişisel veri yazmamaya dikkat edilmelidir; aksi halde günlük dosyasının kendisi bir risk hâline gelir. Etkili bir izleme altyapısı, olayları gerçek zamanlı tespit etmenizi ve müdahale süresini saatlerden dakikalara indirmenizi sağlar.

A10 Sunucu Tarafı İstek Sahteciliği (SSRF)

SSRF, bir saldırganın uygulamayı kandırarak onun adına istek attırmasıdır. Örneğin bir URL'den görsel çeken bir özellik, saldırgan tarafından iç ağdaki servislere veya bulut metadata uçnoktalarına erişmek için kötüye kullanılabilir. Bu da iç sistemlerin haritalanmasına veya kimlik bilgilerinin çalınmasına yol açabilir. Savunma için; dışarıdan gelen URL'leri katı bir beyaz listeyle kısıtlamak, iç ağ segmentasyonu uygulamak, bulut metadata uçnoktalarına erişimi engellemek ve mümkünse istekleri ayrı bir izole ortamdan yapmak gerekir.

Sunucu altyapısı ve güvenlik yapılandırmasını gözden geçiren mühendis

XSS ve SQL injection: en yaygın iki saldırıyı yakından inceleyelim

Enjeksiyon ailesinin iki üyesi, Türkiye'deki projelerde en sık denetlediğimiz ve en sık açık bulduğumuz saldırı türleridir. Bu yüzden ayrı bir başlığı hak ediyorlar.

Cross-Site Scripting (XSS)

XSS, saldırganın bir web sayfasına zararlı JavaScript enjekte etmesiyle gerçekleşir. Bu kod kurbanın tarayıcısında çalışır ve oturum çerezlerini çalabilir, kullanıcı adına işlem yapabilir veya sayfayı tahrif edebilir. Üç temel türü vardır: depolanmış (stored) XSS, yansıyan (reflected) XSS ve DOM tabanlı XSS. En tehlikelisi depolanmış XSS'tir, çünkü zararlı kod veritabanına kaydedilir ve onu gören her kullanıcıyı etkiler.

XSS'e karşı temel savunma çıktı kodlamadır: kullanıcıdan gelen veriyi sayfaya yazarken, içeriği bağlamına uygun biçimde kaçışlamak. Modern çerçeveler bu konuda büyük yardım sağlar; örneğin React, JSX içine konan değerleri varsayılan olarak kaçışlar. Ancak innerHTML benzeri yöntemlerle veya dangerouslySetInnerHTML kullanımıyla bu koruma kolayca devre dışı kalır:

// Tehlikeli: kullanıcı içeriği ham HTML olarak basılıyor
element.innerHTML = kullaniciYorumu

// Güvenli: metin olarak basılıyor, kod olarak yorumlanmıyor
element.textContent = kullaniciYorumu

Content-Security-Policy başlığı, XSS'e karşı güçlü bir ikinci savunma katmanıdır; sayfada hangi kaynaklardan kod çalışabileceğini kısıtlayarak enjekte edilen betiğin çalışmasını engelleyebilir.

SQL injection

SQL injection, A03 başlığında değindiğimiz gibi, kullanıcı girdisinin doğrudan SQL sorgusuna gömülmesinden doğar ve sonuçları yıkıcı olabilir: tüm veritabanının okunması, değiştirilmesi veya silinmesi. Savunma katmanları net bir öncelik sırasına sahiptir: önce parametreli sorgular, sonra girdi doğrulama, ardından en küçük ayrıcalık ilkesiyle yapılandırılmış veritabanı kullanıcıları. Uygulamanın bağlandığı veritabanı kullanıcısının yalnızca ihtiyaç duyduğu tablolara, yalnızca gerekli yetkilerle erişmesi, bir enjeksiyon gerçekleşse bile hasarı sınırlar.

CSRF: sessiz ama tehlikeli bir akraba

Enjeksiyon ailesinin yakın bir akrabası olan siteler arası istek sahteciliği (CSRF), kullanıcının oturumunu kötüye kullanarak onun adına istem dışı işlemler yaptırır. Örneğin oturumu açık bir kullanıcı kötü niyetli bir sayfayı ziyaret ettiğinde, o sayfa kullanıcının haberi olmadan para transferi veya parola değişikliği isteği tetikleyebilir. CSRF'e karşı temel savunma, durum değiştiren her istekte tahmin edilemez bir CSRF belirteci doğrulamak ve çerezleri SameSite özniteliğiyle işaretlemektir. Modern çerçeveler bu korumayı genellikle yerleşik olarak sunar, ancak API tabanlı mimarilerde belirteç tabanlı kimlik doğrulama ile birlikte doğru yapılandırmak gerekir. CSRF görünmez olduğu için sıkça gözden kaçar; oysa basit ve standart önlemlerle büyük ölçüde kapatılabilir.

Güvenlik açıklarını tespit etme: SAST, DAST ve sızma testi

Önlemleri uygulamak kadar, açıkların gerçekten kapandığını doğrulamak da önemlidir. Bunun için üç tamamlayıcı yaklaşım kullanılır. SAST (Statik Uygulama Güvenlik Testi), kaynak kodunu çalıştırmadan analiz ederek zafiyet desenlerini yakalar; geliştirme aşamasında erken uyarı verir. DAST (Dinamik Uygulama Güvenlik Testi), çalışan uygulamaya gerçek saldırılar simüle ederek davranışı test eder. Sızma testi (penetration testing) ise deneyimli güvenlik uzmanlarının manuel olarak sistemi zorladığı, otomatik araçların kaçırdığı iş mantığı açıklarını ortaya çıkaran derinlemesine bir denetimdir.

Olgun bir güvenlik pratiği bu üçünü birlikte kullanır: SAST ve bağımlılık taraması CI/CD hattında her commit'te otomatik çalışır, DAST düzenli aralıklarla yürütülür, sızma testi ise büyük sürümler öncesinde veya yılda en az bir kez yapılır. Bu katmanlı yaklaşım, açıkların hem geliştirme sırasında hem de üretim öncesinde yakalanmasını sağlar.

Otomatik araçların ve planlı testlerin ötesinde, olgun kuruluşlar sorumlu açık bildirimi (responsible disclosure) ve ödül programları (bug bounty) ile dış güvenlik araştırmacılarının katkısından yararlanır. Sitenizde bir güvenlik iletişim dosyası yayımlayarak araştırmacılara nasıl ulaşacaklarını açıkça belirtmek, bir açığın kötüye kullanılmadan önce size bildirilmesi olasılığını artırır. Bu yaklaşım, iç ekibinizin ve araçlarınızın kaçırdığı sıra dışı zafiyetleri ortaya çıkarmanın etkili ve maliyeti öngörülebilir bir yoludur. Ancak böyle bir programın işe yaraması için gelen bildirimleri hızlı değerlendiren ve düzelten bir sürecin önceden kurulmuş olması gerekir; aksi halde bildirimler birikir ve program amacına ulaşmaz. Açık tespitini tek seferlik bir olay değil, sürekli işleyen bir döngü olarak kurgulamak en doğru yaklaşımdır.

Türkiye pazarında web güvenliği ve KVKK uyumu

Türkiye'de faaliyet gösteren işletmeler için web güvenliği yalnızca teknik bir tercih değil, yasal bir yükümlülüktür. Kişisel Verilerin Korunması Kanunu (KVKK), kişisel veri işleyen her kuruluşa verileri uygun teknik ve idari tedbirlerle koruma zorunluluğu getirir. Bir veri ihlali yaşandığında, ihlalin yetkili kuruma ve ilgili kişilere bildirilmesi gerekir; yetersiz güvenlik tedbiri alındığının tespiti durumunda idari para cezaları söz konusu olur.

OWASP Top 10 önlemleri, KVKK'nın talep ettiği teknik tedbirlerin önemli bir bölümünü doğrudan karşılar: erişim kontrolü, şifreleme, günlükleme ve güvenli kimlik doğrulama hem güvenlik hem de uyum açısından temel taşlardır. Bu nedenle güvenlik yatırımını yalnızca saldırılara karşı bir kalkan olarak değil, aynı zamanda yasal riski azaltan bir uyum yatırımı olarak görmek gerekir. Özellikle e-ticaret, fintech ve sağlık alanında çalışan işletmeler için bu uyum, müşteri güveninin de temelini oluşturur.

Güvenli geliştirme yaşam döngüsü (SSDLC) kurmak

Tek seferlik bir güvenlik denetimi, yarın eklenecek yeni bir özelliğin getireceği açığı önlemez. Bu yüzden güvenliği, geliştirme sürecinin her aşamasına yerleştiren bir Güvenli Geliştirme Yaşam Döngüsü (SSDLC) kurmak şarttır. Bu yaklaşım güvenliği projenin sonunda yapılan bir test olmaktan çıkarıp, planlamadan dağıtıma kadar her adıma gömülü bir disipline dönüştürür.

Pratikte SSDLC şu öğelerden oluşur:

Tasarım aşamasında tehdit modelleme yaparak riskleri önceden belirlemek.
Geliştirme sırasında güvenli kodlama standartlarını ve kod incelemesini zorunlu kılmak.
CI/CD hattında SAST ve bağımlılık taramasını otomatik çalıştırmak.
Üretim öncesi DAST ve düzenli sızma testleri uygulamak.
Üretimde sürekli izleme, günlükleme ve olay müdahale planı bulundurmak.

Bu döngüyü kurmak başta yatırım gerektirir, ancak uzun vadede hem ihlal maliyetini hem de düzeltme maliyetini ciddi şekilde düşürür: bir açığı tasarım aşamasında kapatmak, üretimde patlak verdikten sonra kapatmaktan kat kat ucuzdur. Güvenli mimariyi en baştan doğru kurmak için web geliştirme hizmetimiz kapsamında projelerinizi OWASP ilkeleriyle uyumlu biçimde tasarlıyoruz.

Sıkça Sorulan Sorular

OWASP Top 10'u uygulamak küçük işletmeler için de gerekli mi?

Evet. Saldırganların büyük bir kısmı belirli bir hedef seçmez; otomatik araçlarla internette tarama yaparak savunmasız her uygulamayı bulur. Bu nedenle küçük bir kurumsal site bile, basit ve yaygın açıkları kapatmadığı sürece risk altındadır. İyi haber şu ki OWASP Top 10'un büyük çoğunluğu, doğru kurulmuş temel önlemlerle ve makul bir bütçeyle karşılanabilir.

Hangi OWASP kategorisi en sık karşılaşılan açıktır?

Güncel verilerde Bozuk Erişim Kontrolü (A01) en yaygın kategori olarak öne çıkar. Bunun nedeni, yetkilendirme mantığının çok sayıda uçnoktada tekrar tekrar doğru kurulması gereken, hataya açık bir alan olmasıdır. Bu yüzden denetimlerimizde erişim kontrolünü her zaman önceliklendiriyoruz.

Çerçeve (framework) kullanmak beni otomatik olarak güvende tutar mı?

Hayır. Modern çerçeveler XSS ve CSRF gibi bazı saldırılara karşı yerleşik koruma sağlar ve bu büyük bir avantajdır. Ancak iş mantığı açıkları, hatalı erişim kontrolü ve yanlış yapılandırma çerçevenin sorumluluğunda değildir. Çerçeve güçlü bir temeldir, ama güvenli kullanımı geliştiricinin sorumluluğundadır.

Güvenlik denetimini ne sıklıkla yaptırmalıyım?

Otomatik taramalar (SAST ve bağımlılık taraması) her dağıtımda çalışmalıdır. Kapsamlı bir sızma testini ise yılda en az bir kez ve büyük sürüm değişikliklerinden önce yaptırmak iyi bir pratiktir. Sürekli geliştirilen, kullanıcı verisi yoğun uygulamalarda bu sıklık artırılmalıdır.

Bir güvenlik açığı tespit edersem önceliklendirmeyi nasıl yapmalıyım?

Açıkları istismar edilebilirlik ve potansiyel etki üzerinden değerlendirin. Kimlik doğrulama gerektirmeyen, kolayca istismar edilebilen ve hassas veriye ulaşan açıklar en yüksek önceliktir. Erişim kontrolü ve enjeksiyon açıkları genellikle bu sınıfa girer ve derhal ele alınmalıdır.

Sonuç

OWASP Top 10, web güvenliğini soyut bir korku konusundan yönetilebilir bir mühendislik disiplinine dönüştüren değerli bir çerçevedir. Bozuk erişim kontrolünden SSRF'ye kadar on kategorinin her birini anlamak, uygulamanızdaki en yaygın ve en kritik riskleri sistematik olarak kapatmanızı sağlar. Ancak unutulmamalıdır ki bu liste bir başlangıçtır; gerçek güvenlik, tek seferlik bir kontrol listesini değil, geliştirme süreçlerinize gömülmüş sürekli bir kültürü gerektirir. Erişim kontrolünü her istekte doğrulamak, girdiyi asla güvenilir saymamak, bağımlılıkları güncel tutmak ve olup biteni izleyebilmek; bu temel disiplinler bir araya geldiğinde uygulamanızı saldırıların büyük çoğunluğuna karşı dirençli hâle getirir.

KaliteliWebsite olarak İstanbul'dan tüm Türkiye'ye hizmet veren bir yazılım ajansı kimliğiyle, web uygulamalarını OWASP ilkeleriyle uyumlu biçimde tasarlıyor, mevcut sistemleri denetliyor ve güvenlik açıklarını kalıcı olarak kapatıyoruz. Projeleriniz için fiyatlarımız 10.000 TL'den başlıyor ve her potansiyel iş için ücretsiz keşif görüşmesi sunuyoruz. Uygulamanızın güvenlik durumunu birlikte değerlendirmek, KVKK uyumunuzu güçlendirmek veya yeni bir projeye güvenli bir temelle başlamak için bizimle iletişime geçin; size pazarlama vaatleri değil, mühendislik temelli net bir yol haritası sunalım.

OWASP Top 10: Web Güvenliği İçin Kapsamlı Koruma Rehberi