Web Sitesi Güvenliği Nedir, Nasıl Sağlanır? 2026

Web sitesi guvenligi, sitenizin verilerini, kullanicilarinizin kisisel bilgilerini ve sitenin calisirligini yetkisiz erisim, veri sizintisi ve saldirilara karsi koruyan teknik ve idari tedbirlerin butunudur. Pratikte uc katmanda calisir: trafigi sifreleyen HTTPS/TLS, yazilim ve altyapinin guvenli yapilandirilmasi (OWASP Top 10 risklerine kapatma), ve surekli bakim (guncelleme, yedek, izleme). Guvenlik "yapip biten" bir kurulum degil, sitenin yasam dongusu boyunca devam eden bir surectir. Kritik olmasinin dort somut nedeni var: musteri/kullanici verisi, marka itibari, KVKK basta olmak uzere yasal yukumluluk, ve SEO sirasi. Bu dortlu, bir guvenlik acigini ayni anda hem teknik hem ticari hem hukuki bir riske donusturur.

Guvenligi cogu firma "yedekte dururuz, basimiza gelince bakariz" diye erteler; oysa bir saldiri veya veri ihlali gerceklestiginde geri donulmez maliyetler ayni anda devreye girer. Bu mantik hatasinin nedeni, guvenligin gorunmez olmasidir: dogru kurulmus bir guvenlik katmani, hicbir sey olmadigi icin fark edilmez; ne zaman ki bir olay yasanir, o zaman yoklugu gorunur hale gelir. Oysa bu yokluk genellikle zaten olusmustur, sadece henuz somurulmemistir. Asagida web guvenliginin neden ertelenmemesi gereken bir oncelik oldugunu dort eksen uzerinden somutlastiriyoruz. Yeni bir site kuruyorsaniz bu eksenleri en bastan planlamak, sonradan eklemekten cok daha ucuzdur; web sitesi nasil yapilir rehberimizdeki adim sirasinda SSL ve guvenlik, ucuncu ve dorduncu adim olarak bilincli sekilde tasarim ve gelistirmeden once konumlandirilmistir. Guvenligi gelistirmenin ardindan "ekleme" olarak dusunmek, temeli atilmis bir binaya sonradan kolon eklemeye benzer: mumkun ama maliyetli, riskli ve cogu zaman eksik kalir.

Web sitesi guvenligi tam olarak neyi korur?

Web sitesi guvenligi tek bir "site"yi degil, birbirine bagli uc varligi korur: veriyi, erisim/calisirligi, ve butunluk/guveni. Bu uc varlik klasik bilgi guvenligi terminolojisinde gizlilik (confidentiality), erisilebilirlik (availability) ve butunluk (integrity) baslıklariyla anilir; web baglaminda her birinin somut karsiligi vardir ve bir saldiri genellikle birden fazlasini ayni anda hedefler.

Birincisi veri (gizlilik): ziyaretcinin formda biraktigi ad-soyad, e-posta, telefon, adres; e-ticarette siparis ve odeme bilgileri; uye giris parolalari. Bu veriler ele gecirildiginde dogrudan ucuncu sahislara satilir veya kotuye kullanilir. Ikincisi erisim ve calisirlik (erisilebilirlik): sitenizin ayakta kalmasi, yonetim panelinizin yalnizca sizin kontrolunuzde olmasi, bir DDoS saldirisi veya fidye yazilimi karsisinda hizmet vermeye devam edebilmesi. Ucuncusu butunluk ve guven (integrity): sayfalarinizin degistirilmemis, kotu amacli kod (malware, gizli yonlendirme, kripto madenci script'i) enjekte edilmemis, ziyaretcinizin tarayicisinda "guvenli degil" uyarisi cikmamis olmasi. Sayfa tahrifi (defacement) ve gizli spam enjeksiyonu bu ucuncu varliga yapilan en yaygin saldirilardir; cogu zaman site sahibi haftalarca fark etmez.

Bu uc varligi koruyan temel teknik tabaka HTTPS/TLS'tir. Trafigi sifreler, sunucunun kimligini dogrular ve veri butunlugunu saglar; boylece bir saldirgan ortadaki adam (man-in-the-middle) konumuna gecip formdan gecen veriyi okuyamaz veya sayfayi yolda degistiremez. "SSL sertifikasi" yaygin kullanilan terim olsa da guncel protokol teknik olarak TLS'tir (gunumuzde TLS 1.2 ve 1.3 kullanilir); Let's Encrypt ile ucretsiz alinabilir ve cogu hosting otomatik saglar. HTTPS artik opsiyonel degil, zorunlu bir temeldir: hem Google'in bir siralama sinyalidir hem de tarayicilarin "guvenli degil" uyarisini engeller. Bu nedenle altyapi kurarken sertifikayi ilk gun devreye almak gerekir; domain, hosting ve SSL altyapi rehberimizde bu zincirin nasil kurulacagini detaylandiriyoruz. HTTPS'in tek basina yeterli olmadigini da vurgulamak gerekir: sifreli bir baglanti, arkasindaki uygulama guvenli degilse yalnizca "guvenli bir kanaldan guvensiz bir uygulamaya" ulasmanizi saglar. Bu yuzden sifreleme zorunlu temel, ama bitis degil baslangictir.

Veri ve kullanici guveni: bir ihlal neyi yikar?

Kisisel veri isleyen her site, KVKK terminolojisiyle bir "veri sorumlusudur". Bir form, bir uyelik sistemi ya da bir iletisim kutusu bile kisisel veri toplar; yani veri sorumlulugu yalnizca buyuk e-ticaret sitelerinin degil, tek sayfalik bir kurumsal tanitim sitesinin bile yukumlulugudur. Bu verilerin sizmasi yalnizca teknik bir kayip degildir; toplanan e-posta ve telefonlar spam ve dolandiricilik kampanyalarinda kullanilir, parolalar baska servislerde denenir (credential stuffing — kullanicilar ayni parolayi cok yerde kullandigi icin bir sitedeki sizinti zincirleme baska hesaplari da acar), e-ticarette siparis ve adres bilgileri ifsa olur. Guvenli form ve giris tasariminin temel uygulamalari bu yuzden pazarliksizdir:

• Sunucu tarafi dogrulama: Tarayicidaki (istemci) kontroller kolayca atlatilir; her girdi mutlaka sunucuda yeniden dogrulanmalidir.
• CSRF token: Oturum acmis kullanicinin bilgisi disinda istek gonderilmesini (cross-site request forgery) engeller.
• Rate-limit: Ayni IP veya hesaba dakikada sinirli deneme hakki tanir; kaba kuvvet (brute force) parola denemelerini ve form botlarini durdurur.
• Guclu parola politikasi + iki adimli dogrulama (2FA): Calinmis tek bir parolanin tek basina yetmemesi icin ikinci faktor sart.
• Oturum guvenligi: HttpOnly ve Secure cerez bayraklari, makul oturum suresi, cikista oturum sonlandirma.
• Girdi temizleme (sanitization): Kullanicidan gelen her veri, veritabani sorgusuna veya HTML'e gomulmeden once temizlenir; bu, injection ve XSS saldirilarinin onunu keser.

Bu saldiri yuzeyinin haritasi tahmine degil, sektor standardina dayanir. OWASP Top 10'un guncel surumu 2025 (8. baski), 175.000'den fazla CVE analizine dayanir ve en kritik web uygulamasi risklerini siralar. Asagidaki tablo, en sik karsilastigimiz bes maddeyi site sahibi acisindan pratik karsiligiyla ozetliyor; tam liste on maddedir:

Bu surumde dikkat edilmesi gereken yapisal degisimler var. Security Misconfiguration besinci siradan ikinci siraya yukseldi — yani "kod hatasi" degil, "yanlis ayar" giderek daha buyuk bir tehdit; cogu sitenin acigi karmasik bir zafiyetten degil, acik birakilmis bir yonetim paneli veya degistirilmemis varsayilan paroladan kaynaklanir. Daha da onemlisi, Software Supply Chain Failures (A03) ve Mishandling of Exceptional Conditions (A10) bu surumde listeye yeni girdi. Yani risk artik yalnizca sizin yazdiginiz koddan degil, kullandiginiz ucuncu taraf eklenti, tema ve kutuphanelerden de geliyor. Bilinen aciklarin (CVE) cogu, guncellenmemis bilesenlerden somurulur; saldirgan genellikle sizi hedef almaz, otomatik tarayicilarla internetteki "bilinen acigi olan eski surum"leri tarar ve bulduguna girer. Bu da bizi dogrudan bakim disiplini ve altyapi secimi konusuna baglar; cunku farkli altyapilar farkli buyuklukte bakim yuku ve saldiri yuzeyi tasir. Hangi altyapida ne kadar bakim yuku tasiyacaginizi CMS secimi rehberimizde, hazir ile ozel cozumun guvenlik/bakim dengesini ise hazir site mi ozel yazilim mi yazimizda karsilastiriyoruz.

Itibar ve SEO: gorunmeyen ama olculebilir maliyet

Bir saldirinin en gec fark edilen ama en uzun suren hasari itibardir. Tarayicida "guvenli degil" uyarisiyla karsilasan ziyaretci, formu doldurmadan, sepeti tamamlamadan cikar; bu, doğrudan donusum kaybidir ve cogu zaman analytics'te "yuksek hemen cikma" olarak gorunur ama nedeni anlasilmaz. Sayfasi ele gecirilip spam icerik (sahte ilac, kumar, taklit urun linkleri) enjekte edilmis bir site, Google tarafindan "zararli site" veya "ele gecirilmis icerik" olarak isaretlenebilir ve arama sonuclarindan dusebilir. Burada guvenlik ve SEO ic ice gecer: HTTPS bir siralama sinyalidir, ele gecirilmis sayfalar indeksten dusurulebilir, Search Console'a guvenlik sorunu uyarisi duser ve bir guvenlik olayi sonrasi toparlanma kaybedilen organik trafigi geri kazanmaktan cok daha uzun surer. Sitenizin hizi ve SEO sagligini olcmek istiyorsaniz Core Web Vitals rehberimiz ve teknik SEO denetimi rehberimiz ayni zamanda guvenlik gostergelerine de dolayli isik tutar; cunku duzenli denetlenen bir site, ele gecirilmis bir sayfayi cok daha hizli fark eder.

Musterilerimizde gordugumuz tablo sudur: bir veri ihlali ya da defacement (sayfa tahrifi) olayi yasanan firma, teknik temizligi birkac gunde tamamlasa bile musteri guvenini ve arama gorunurlugunu aylar boyunca geri kazanmaya calisir. Olayin maliyeti uc dalgada gelir. Ilk dalga aniktir: site kapali kalir veya kara listeye duser, satis durur. Ikinci dalga teknik temizlik ve adli analizdir: zararli kod temizlenir, tum parolalar sifirlanir, acigin nasil girildigi bulunur. Ucuncu ve en uzun dalga ise itibar onarimidir: arama siralarinin geri gelmesi, "guvenli degil" damgasinin kalkmasi, ve en onemlisi musterinin yeniden guvenmesi. Ozellikle kurumsal ve B2B sitelerde, sitenin temel isi "guven insa etmek" oldugu icin bir guvenlik olayinin verdigi hasar dogrudan satis hunisini vurur; potansiyel musteri, verisini koruyamayan bir firmanin isini de iyi yapamayacagini varsayar. Guvenin sitenizin merkezi bir varligi oldugu B2B/kurumsal baglamda neyin olmazsa olmaz oldugunu kurumsal web sitesi rehberimizde ve B2B web sitesi tasarimi rehberimizde ele aliyoruz; guvenlik, oralarda anlatilan "guvenilirlik sinyalleri"nin gorunmeyen altyapisidir. Referans logolari, sertifikalar ve gercek ekip bilgisi ne kadar guven veriyorsa, bir guvenlik uyarisi da o kadar hizla bu guveni yikar.

KVKK ve yasal zorunluluk: guvenlik artik tercih degil

Turkiye'de web guvenligini "iyi olsa guzel olur" kategorisinden cikaran sey KVKK'dir. KVKK m.12, kisisel veri isleyen sitelere veri guvenligine iliskin teknik ve idari tedbirleri alma yukumlulugu getirir. Bu, somut olarak HTTPS, sifreleme, erisim kontrolu (kim hangi veriye erisebilir), log tutma ve veri ihlali bildirimi anlamina gelir. "Idari tedbir" boyutu cogu zaman atlanir: yalnizca sunucu ayarlari degil, personelin yetkilendirilmesi, parola politikasi, ucuncu taraflarla veri isleme sozlesmeleri de bu kapsamdadir. Yani bir guvenlik acigi yalnizca teknik bir hata degil, ayni zamanda hukuki bir risktir: ihlal halinde idari para cezasi ve Kurul'a bildirim yukumlulugu gundeme gelir; Kurul, gerekli teknik tedbirleri almamis olmayi basli basina bir ihlal sebebi sayar. Ayrica KVKK 2026 yorumunda aydinlatma, "doküman" degil "sürec" olarak yorumlaniyor — yani matbu bir metin yapistirmak yetmez, verinin toplanmasindan silinmesine kadar tum yasam dongusunun belgelenmis ve guvenli olmasi beklenir.

Bu yasal cerceveyi tamamlayan iki nokta daha var. Birincisi, AB'ye urun veya hizmet satan firmalar icin Avrupa Erisilebilirlik Yasasi'nin (EAA) 28 Haziran 2025'te yururluge girmesiyle birlikte erisilebilirlik de bir uyum boyutu olarak tabloya eklendi; e-ticaret, bankacilik, e-kitap gibi alanlarda EN 301 549 / WCAG 2.1 AA uyumu zorunlu hale geldi ve ihlal cezasi ulkeye gore degisse de yuksek olabiliyor. Guvenlik ve uyum giderek tek bir "yasal saglamlik" basligi altinda dusunuluyor; bu boyutu web erisilebilirligi rehberimizde ayrintilandiriyoruz. Ikincisi, cerez ve aydinlatma metni duzeni: KVKK, aydinlatma metni ile acik riza/ticari ileti iznini ayri ayri duzenlemeyi gerektirir ve KVKK'nın güncel İlke Kararı bunu pekistirmistir. Siteye girer girmez ekrana cikan, zorunlu olmayan analitik/pazarlama cerezleri icin acik riza alinmadan calistirilan bir cerez bandi ya da tek kutuda "her seyi kabul ediyorum" yaklasimi hukuken sakincalidir; Kurul, cerez aydinlatma/riza eksikligine ceza vermistir. Bu, guvenligin yalnizca sunucu tarafinda degil, kullaniciyla kurulan veri iliskisinin tasariminda — yani arayuzde ve metinlerde — de basladigini gosterir. E-ticaret yapiyorsaniz buna 6502 sayili Kanun ve Mesafeli Sozlesmeler Yonetmeligi geregi mesafeli satis sozlesmesi, on bilgilendirme formu ve iade/cayma kosullari da eklenir.

Kisaca: web guvenligi; veriyi, itibari, arama gorunurlugunu ve yasal uyumu ayni anda koruyan bir omurgadir. Bu dort eksen birbirinden bagimsiz degildir — bir veri ihlali ayni anda dordunu birden tetikler: veri sizar, itibar zedelenir, arama sirasi duser ve yasal yukumluluk dogar. Iste bu yuzden guvenligi tek bir "onlem" degil, butunsel bir tasarim ilkesi olarak ele almak gerekir. Bir sonraki bolumlerde bu omurgayi pratikte nasil kurdugunuzu (HTTPS yapilandirmasi, guncelleme disiplini, yedekleme stratejisi, WAF/CDN katmani ve guvenli giris akisi) adim adim ele alacagiz. Mevcut sitenizin bu eksenlerde nerede durdugunu gormek isterseniz ozel yazilim ve web gelistirme hizmetimiz kapsaminda bir guvenlik ve altyapi degerlendirmesi yapiyor, sonuclari somut bir yol haritasina baglıyoruz; baslamak icin ucretsiz analiz formundan sitenizi inceletebilirsiniz.

Web Sitesi Güvenliğinin Temeli: HTTPS, Güncelleme, Yedek ve 2FA Neden Vazgeçilmez?

Web güvenliğinin temeli; trafiği şifrelemek (HTTPS/TLS), tüm bileşenleri güncel tutmak, güçlü parola ve iki faktörlü doğrulama (2FA) ile girişi korumak, düzenli ve site dışı yedek almak ve herkese yalnızca işine yetecek kadar yetki vermektir (en az yetki ilkesi). Bu beş katman, müşterilerimizde gördüğümüz ihlallerin büyük çoğunluğunu daha gerçekleşmeden engeller. Çünkü saldırıların önemli kısmı sıfırdan keşfedilen "süper açıklar" değil; süresi geçmiş bir sertifika, güncellenmemiş bir eklenti, "123456" parolalı bir admin hesabı ya da hiç test edilmemiş bir yedek gibi temel ihmallerdir. OWASP Top 10:2025 listesinde de en üst sıralarda yetki kontrolü zafiyetleri (A01 Broken Access Control) ve güvenlik yapılandırma hataları (A02 Security Misconfiguration) yer alıyor; ikincisi bir önceki sürümde 5. sıradayken 2. sıraya yükseldi. Yani sektör verisi de "egzotik saldırı" değil, "temeli doğru kurmak" tarafına işaret ediyor.

Bir benzetmeyle çerçeveleyelim: bu beş katman, bir binanın çelik kapısı (HTTPS), bakımlı tesisatı (güncelleme), iki anahtarlı kilidi (2FA), oda oda erişim kartları (en az yetki) ve yangın sonrası geri dönüş için kasadaki kopya planlardır (yedek). Hiçbiri tek başına binayı güvenli kılmaz; ama beşi birden, hırsızın kapasitesini "kolay hedef ara" düzeyine indirir. Müşterilerimizde gördüğümüz pratik gerçek şudur: otomatik saldırı botları en zayıf, en kolay hedefi arar; temelleri doğru kuran site, bu taramanın çok büyük kısmında "uğraşmaya değmez" olarak elenir.

Bu bölümde her bir temel katmanı; ne olduğu, neden gerektiği ve pratikte nasıl uygulanacağı sırasıyla ele alıyoruz. Altyapı tarafındaki (alan adı, hosting, sertifika sağlayıcı seçimi) ayrıntılar için domain, hosting ve SSL altyapısı rehberimize; güvenliğin neden tasarım aşamasından başlaması gerektiğine dair bütüncül bakış için ise web sitesi güvenliği temel rehberimizin diğer bölümlerine bakabilirsiniz.

HTTPS / TLS: Artık "Opsiyonel" Değil, Zemin Şartı

HTTPS, sitenizle ziyaretçi arasındaki tüm trafiği şifreleyen, karşı tarafın gerçekten sizin sunucunuz olduğunu doğrulayan ve verinin yolda değiştirilmediğini garanti eden temel güvenlik katmanıdır. Günlük dilde "SSL" dense de teknik olarak güncel protokol TLS'tir (yaygın sürümler TLS 1.2 ve TLS 1.3); SSL ismi alışkanlıktan kalmıştır. HTTPS olmadan, kullanıcının girdiği parola, form bilgisi veya ödeme verisi açık metin olarak ağ üzerinde taşınır ve aradaki herhangi bir noktada (halka açık Wi-Fi, ele geçirilmiş bir ağ cihazı, kötü niyetli bir ara sunucu) okunabilir.

HTTPS bugün üç ayrı nedenle zorunlu hâle gelmiştir. Birincisi güvenlik: şifreleme, kimlik doğrulama ve veri bütünlüğü sağlar. İkincisi SEO: Google, HTTPS'i bir sıralama sinyali olarak kullanır. Üçüncüsü güven: HTTPS olmayan sitelerde modern tarayıcılar adres çubuğunda "Güvenli değil" uyarısı gösterir; bu uyarı, özellikle form ve ödeme sayfalarında dönüşümü doğrudan düşürür. KVKK açısından da kritiktir: kişisel veri işleyen bir sitede, verinin aktarım sırasında şifrelenmesi (HTTPS) KVKK madde 12'nin gerektirdiği teknik tedbirlerin en temel parçasıdır. Yani HTTPS'i atlamak yalnızca teknik bir eksik değil, aynı zamanda hukuki bir açıktır.

İyi haber, bu katmanın maliyetsiz ve büyük ölçüde otomatik olmasıdır. Let's Encrypt ücretsiz sertifika verir ve çoğu modern hosting (yönetilen WordPress hosting, Vercel, Netlify, Cloudflare Pages dâhil) sertifikayı otomatik kurar ve yeniler. Sertifika türleri arasında kısa bir ayrım faydalı olur:

Sık karşılaşılan bir yanlış anlama: "EV sertifikam var, daha güvenliyim." Şifrelemenin gücü DV ile EV arasında değişmez; fark, ziyaretçiye gösterilen kurumsal kimlik doğrulamasındadır. Tipik bir kurumsal site veya e-ticaret için DV (ücretsiz Let's Encrypt) şifreleme açısından tamamen yeterlidir. Pratikte dikkat edilmesi gerekenler:

• Tüm trafiği zorla HTTPS'e yönlendirin: http:// üzerinden gelen istekleri kalıcı (301) olarak https:// adresine taşıyın; "yarı şifreli" bir site, hiç şifresiz kadar risklidir.
• Karışık içeriği (mixed content) temizleyin: HTTPS sayfa içinde http:// ile çağrılan görsel, font veya script tarayıcıda uyarı üretir; tüm kaynakları https:// ya da göreli yol ile çağırın. Eski bir siteyi HTTPS'e taşırken en sık yaşanan sorun budur.
• HSTS başlığını ekleyin: Strict-Transport-Security başlığı, tarayıcıya "bu siteye sadece HTTPS ile bağlan" der ve ilk istekteki açığı (SSL stripping) kapatır.
• Güncel protokol ve şifre takımlarını kullanın: Sunucuda TLS 1.2 ve 1.3'ü açın, eski ve kırılmış protokolleri (SSLv3, TLS 1.0/1.1) kapatın. Çoğu yönetilen hosting bunu varsayılan yapar; özel sunucuda ayarı doğrulayın.
• Sertifika yenilemesini izleyin: Otomatik yenileme genelde sorunsuzdur ama bir aksamada sertifika süresi dolarsa site komple "güvensiz" görünür; basit bir izleme/uyarı (süre dolmadan 14 gün önce bildirim) kurun. Müşterilerimizde gördüğümüz en kolay önlenebilir kesintilerden biri, sessizce dolan sertifikadır.

HTTPS bir hız konusu değil ama performansla iç içedir: TLS 1.3 ve HTTP/2 gibi modern protokoller doğru yapılandırıldığında ek gecikme neredeyse fark edilmez. Sertifika ve protokol tarafının altyapısal kurulumunu ayrıntılı ele aldığımız altyapı rehberimiz bu adımın sağlayıcı seçimini de kapsıyor. Yeni bir alan adı alırken HTTPS hazırlığını da gözeten domain sorgulama aracımızdan başlayabilirsiniz.

Güncel Tutma: İhlallerin Çoğu "Bilinen" Açıklardan Gelir

Bir sitenin güvenliğindeki en yaygın ve en kolay önlenebilir zayıflık, güncellenmemiş bileşenlerdir. Saldırıların büyük kısmı, henüz kimsenin bilmediği sıfırıncı gün açıklarından değil; kamuya açık şekilde duyurulmuş ve yaması çıkmış ama uygulanmamış zafiyetlerden (CVE) sömürülür. Açık ilan edildiği an, hem yama hem de o açığı tarayan otomatik botlar aynı anda dolaşıma girer; güncellemeyi geciktiren her gün, bu botlara açık kapı bırakır. Burada zamanlama kritiktir: bir zafiyet duyurulduktan sonra otomatik tarama trafiği genellikle saatler içinde başlar, bu yüzden "ay sonunda toplu güncellerim" yaklaşımı pratikte güvenli değildir.

OWASP Top 10:2025'te bu gerçeğin altı kalın çizilmiştir: listeye yeni giren A03 Software Supply Chain Failures (yazılım tedarik zinciri zafiyetleri) maddesi, doğrudan kullandığınız üçüncü taraf bileşenlerin (eklenti, tema, kütüphane, paket) risklerine işaret eder. Yani artık sadece kendi kodunuz değil, sitenize dâhil ettiğiniz her dış parça da sizin sorumluluğunuzdadır. Bu, modern web'in gerçeğidir: bir WordPress sitesi onlarca eklenti, bir Next.js projesi ise yüzlerce npm paketi taşıyabilir ve bunlardan herhangi birindeki açık tüm siteyi riske atabilir.

Özellikle WordPress bağlamında bu kritiktir; çünkü WordPress tüm web sitelerinin yaklaşık %41,9'unu çalıştırır (Haziran 2026, W3Techs) ve ekosisteminin gücü olan on binlerce eklenti, aynı zamanda en geniş saldırı yüzeyidir. Tam da bu yaygınlık, WordPress'i otomatik saldırı botları için en cazip hedef hâline getirir: en çok kullanılan platform, en çok hedeflenen platformdur. Müşterilerimizde gördüğümüz tablo nettir: WordPress'te asıl risk çekirdeğin kendisi değil, güncellenmemiş veya terk edilmiş üçüncü taraf eklentiler ile zayıf admin parolalarıdır. Pratik güncelleme disiplini şöyle olmalı:

• Üç katmanı da güncel tutun: CMS çekirdeği (WordPress vb.), tema ve tüm eklentiler düzenli güncellenmeli. Birini güncelleyip diğerini unutmak zinciri kırmaz; saldırgan en zayıf halkadan girer.
• Kullanılmayanı silin, pasif yapmayın: Devre dışı bırakılmış ama dosyaları sunucuda duran bir eklenti hâlâ sömürülebilir. İhtiyaç yoksa tamamen kaldırın. "Belki sonra lazım olur" diye tutulan pasif eklentiler, en sessiz açık kaynaklarındandır.
• Eklenti seçiminde "bakımlı mı" diye bakın: Son güncelleme tarihi eski, aktif kurulum sayısı düşük veya geliştiricisi terk etmiş eklentilerden kaçının. Kurulum öncesi son güncelleme tarihine, sürüm uyumluluğuna ve destek geçmişine bakmak birkaç dakikanızı alır ama büyük risk azaltır. Az ama güvenilir eklenti, çok ama bakımsız eklentiden iyidir.
• Önce staging'de deneyin: Büyük güncellemeleri doğrudan canlıya uygulamayın; bir kopya (staging) ortamında test edip sonra canlıya alın. Bu, hem güvenliği hem site bütünlüğünü korur; uyumsuz bir güncellemenin canlıyı çökertmesini önler.
• Otomatik güvenlik yamalarını açın, büyük sürümleri kontrollü alın: Küçük güvenlik yamalarının otomatik uygulanması (örneğin WordPress'in minör sürüm otomasyonu) makuldür; ana sürüm geçişlerini ise staging testiyle planlayın.
• Bağımlılıkları izleyin: Özel yazılım projelerinde (Next.js, React vb.) npm paketleri için güvenlik denetimi (audit) ve otomatik bağımlılık güncelleme araçları kullanın; tedarik zinciri riskini buradan yönetin. Bir paketin geçişli bağımlılıkları (sizin doğrudan eklemediğiniz alt paketler) bile risk taşıyabilir.

Güncelleme yükü, platform seçiminizle doğrudan ilişkilidir. Aşağıdaki tablo, üç ana yaklaşımda güvenlik bakım sorumluluğunun kimde olduğunu özetliyor:

Bu denge, hangi altyapıyı seçeceğinize karar verirken önemli bir kriterdir ve CMS seçimi rehberimizde ile hazır site mi özel yazılım mı karşılaştırmamızda bu konuyu güvenlik bakım yükü açısından da ele alıyoruz. Mevcut sitenizin hangi altyapı üzerinde çalıştığını ve teknolojisini görmek için e-ticaret altyapı tespit aracımızı da kullanabilirsiniz.

Güçlü Parola ve İki Faktörlü Doğrulama (2FA)

Yönetim paneline (admin) giriş, bir sitenin en değerli kapısıdır; o kapı düşerse diğer tüm önlemler anlamını yitirir. Bu yüzden giriş güvenliği iki ayrı katmanla kurulmalıdır: bildiğiniz bir şey (güçlü parola) ve sahip olduğunuz bir şey (telefonunuza/uygulamanıza gelen ikinci faktör). OWASP Top 10:2025'te A07 Authentication Failures (kimlik doğrulama zafiyetleri) maddesi tam olarak bu alanı kapsar.

Sadece parolaya güvenmek neden yetersiz? Çünkü zayıf veya tekrar kullanılan parolalar, otomatik kaba kuvvet (brute-force) ve veri sızıntılarından elde edilen parola listeleriyle denenen saldırılara (credential stuffing) açıktır. Bu saldırı türünde saldırgan parolanızı "tahmin etmez"; başka bir sitede sızmış parolanızı, aynısını burada da kullandığınız varsayımıyla otomatik dener. Bu yüzden parolanın yalnızca güçlü değil, her hesapta benzersiz olması da şarttır. 2FA, parola ele geçirilse bile saldırganın ikinci faktör olmadan içeri girememesini sağlar; bu, tek başına en yüksek getirili güvenlik önlemlerinden biridir. Pratik kurallar:

• Güçlü ve benzersiz parola: Her hesap için uzun, tahmin edilemez ve başka yerde kullanılmayan parola. Uzunluk, karmaşıklıktan daha belirleyicidir; birden çok kelimeden oluşan uzun bir parola cümlesi (passphrase), kısa ama "karışık" bir paroladan daha güçlüdür. Parola yöneticisi (password manager) kullanmak, bunu sürdürülebilir kılan en pratik yoldur.
• Tüm kritik girişlerde 2FA: Yalnızca site admin paneli değil; hosting paneli, alan adı yönetimi, e-posta ve DNS hesapları da 2FA ile korunmalı. Bunlardan birinin ele geçmesi sitenin tamamını riske atar. Örneğin alan adı yönetim hesabı ele geçirilirse, saldırgan trafiği kendi sunucusuna yönlendirebilir; e-posta hesabı ele geçirilirse, diğer servislerde "parolamı unuttum" akışıyla zincirleme erişim sağlayabilir.
• Doğru 2FA yöntemi: Mümkünse SMS yerine kimlik doğrulayıcı uygulama (authenticator / TOTP) veya donanım anahtarı tercih edin; SMS, SIM değiştirme (SIM swap) saldırılarına daha açıktır. Yine de hiç 2FA olmamasından SMS 2FA bile çok daha iyidir; "en iyi" yöntemi ararken "iyi" yöntemi ertelemeyin.
• Kaba kuvveti sınırlayın (rate-limit): Giriş formuna deneme sınırı koyun; belirli sayıda hatalı denemeden sonra geçici kilit veya CAPTCHA devreye girsin. Bu, otomatik bot saldırılarını boğar ve giriş sayfasını sürekli deneyen botların yükünü de azaltır.
• Varsayılanları değiştirin: "admin" kullanıcı adı, varsayılan giriş yolu, ilk kurulum parolaları gibi tahmin edilebilir değerleri mutlaka değiştirin. Tahmin edilebilir her ayar, saldırganın işini kolaylaştıran bir yapılandırma hatasıdır (A02 Security Misconfiguration). Botların ilk denediği şey tam olarak bu varsayılanlardır.

Giriş güvenliği, formların kendisinin güvenliğiyle de iç içedir: sunucu tarafı doğrulama, CSRF token, oturum güvenliği (güvenli ve HttpOnly çerezler, makul oturum süresi) ve girdi temizleme (injection/XSS önleme) bir bütün olarak ele alınmalıdır. Tarayıcı tarafındaki doğrulama yalnızca kullanıcı deneyimi içindir; gerçek güvenlik her zaman sunucu tarafında sağlanmalıdır, çünkü saldırgan tarayıcıyı atlayıp doğrudan sunucuya istek gönderebilir. Bunların ayrıntısını güvenlik rehberimizin uygulama katmanı bölümlerine bırakıyoruz; burada vurgu, "kapıyı sağlam kilitlemek" üzerine.

Düzenli, Otomatik ve Site Dışı Yedekleme

Yedekleme, bir güvenlik önlemi değil; tüm önlemler aşıldığında devreye giren kurtarma planınızdır. Bir saldırı, hatalı bir güncelleme, fidye yazılımı (ransomware) veya basit bir insan hatası karşısında siteyi geri getirmenin tek garantili yolu sağlam bir yedektir. Müşterilerimizde gördüğümüz en acı tablo, "yedeğimiz var" sanılıp kriz anında o yedeğin ya eksik ya bozuk ya da hiç test edilmemiş olduğunun anlaşılmasıdır. Yedek, ancak geri yüklendiğinde yedektir; saklandığı yerde duran ama açılıp denenmemiş bir dosya, çoğu zaman sahte bir güvenlik hissinden ibarettir.

İyi bir yedekleme stratejisinin dört özelliği vardır:

• Düzenli ve otomatik: Elle alınan yedek, er ya da geç unutulur. Sitenin güncellenme sıklığına göre günlük veya en azından haftalık otomatik yedek kurun; e-ticaret gibi her gün sipariş/müşteri verisi değişen sitelerde aralığı sıklaştırın, hatta günde birden çok kez alın. Burada "ne kadar veri kaybını göze alabilirim?" sorusu yedekleme aralığını belirler.
• Sürümlü (versioned): Tek bir "son yedek" yetmez. Bir sorun fark edilmeden günlerce sürebilir; birden fazla geçmiş sürümü saklayın ki temiz bir noktaya dönebilesiniz. Sadece son yedeği tutarsanız ve zararlı kod günler önce bulaştıysa, o zararlı kod yedeğe de kopyalanmış olur; geri yüklediğinizde sorunu da geri yüklersiniz.
• Site dışı (off-site): Yedek, sitenin barındığı sunucudan ayrı bir yerde durmalı. Sunucu komple ele geçer, çöker veya fidye yazılımıyla şifrelenirse, aynı sunucudaki yedek de gider. Ayrı bir bulut depolama veya farklı sağlayıcı şarttır. Yaygın bir kural olan 3-2-1 yaklaşımı bunu özetler: en az üç kopya, iki farklı ortamda, biri site dışında.
• Geri yükleme testi yapılmış: Test edilmemiş yedek, yedek sayılmaz. Geri yükleme sürecini periyodik olarak deneyin; hem yedeğin gerçekten çalıştığını doğrularsınız hem de kriz anında nasıl geri döneceğinizi önceden bilirsiniz. Tatbikatı kriz gününe bırakmak, en kötü zamanda öğrenmek demektir.

Yedeklemenin neyi kapsadığı da önemlidir: hem dosyalar (tema, eklenti, yüklenen medya, kod) hem de veritabanı (içerik, kullanıcılar, siparişler, ayarlar) birlikte yedeklenmeli; yalnızca birini almak eksik bir kurtarmaya yol açar. Yedekleme aynı zamanda yasal bir gerekliliğin de parçasıdır: KVKK madde 12, kişisel veri işleyen veri sorumlusundan verinin kaybolmasına ve hukuka aykırı erişime karşı teknik tedbirler almasını ister; düzenli ve güvenli yedek, bu tedbirlerin doğal bir parçasıdır. Üstelik yedeklerin kendisi de kişisel veri içerdiği için şifreli ve erişimi sınırlı tutulmalıdır; korumasız bir yedek dosyası, başlı başına bir veri ihlali kaynağı olabilir. Bir veri kaybı yalnızca operasyonel değil, hukuki bir risktir de.

En Az Yetki İlkesi (Least Privilege)

En az yetki ilkesi, her kullanıcıya ve her bileşene yalnızca işini yapmaya yetecek kadar erişim vermek demektir; ne bir fazlası. Bu ilke, OWASP Top 10:2025'in 1. sırasındaki A01 Broken Access Control (bozuk yetki kontrolü) maddesinin doğrudan panzehridir. Mantık basittir: bir hesap ele geçirildiğinde verdiği zarar, o hesabın sahip olduğu yetki kadardır. Herkesin "yönetici" olduğu bir sitede tek bir ele geçirilmiş hesap, sitenin tamamını teslim eder; oysa yetkisi içerik girmeyle sınırlı bir hesap ele geçtiğinde zarar da o sınırla çevrilidir.

Pratikte en az yetki şöyle uygulanır:

• Rol bazlı erişim verin: CMS'lerin hazır rolleri vardır (örneğin WordPress'te abone, katkıda bulunan, yazar, editör, yönetici). İçerik girecek kişiye yönetici değil, editör/yazar rolü verin. Herkese yönetici vermek, en sık görülen yapılandırma hatalarından biridir ve gereksiz risk üretir.
• Ayrı ve kişisel hesaplar: Ekip üyeleri ortak tek bir admin hesabını paylaşmasın; herkesin kendi hesabı olsun. Böylece kimin ne yaptığı loglardan izlenebilir ve biri ayrıldığında sadece o hesap kapatılır; ortak parolayı tüm ekibe yeniden dağıtma zorunluluğu doğmaz.
• Ayrılanın erişimini hemen kesin: İşten ayrılan çalışan, biten ajans/freelancer ilişkisi sonrası ilgili hesapları derhal devre dışı bırakın. Unutulan aktif hesaplar, en sessiz güvenlik açığıdır; aylar sonra ele geçtiğinde kimsenin haberi bile olmaz.
• Veritabanı ve sunucu yetkilerini de daraltın: Uygulamanın bağlandığı veritabanı kullanıcısına yalnızca ihtiyaç duyduğu işlemler için yetki verin; her şeye yetkili (root) bağlantılardan kaçının. Aynı şekilde dosya/dizin izinlerini de gereğinden geniş bırakmayın.
• Üçüncü taraf entegrasyonlarda da uygulayın: Bir ödeme, analitik veya pazarlama aracına API erişimi verirken yalnızca gerekli kapsamı (scope) tanımlayın. "Tam erişim" yerine "yalnızca okuma" yetiyorsa onu seçin.
• Yetkileri periyodik gözden geçirin: "Bir kere ver, unut" olmaz. Belirli aralıklarla kimin hangi yetkiye sahip olduğunu denetleyin; zamanla biriken gereksiz erişimleri (yetki kayması) temizleyin.

En az yetki ilkesi, güçlü parola ve 2FA ile birlikte çalışır: kapıyı sağlam kilitlersiniz (2FA), içeri girene de yalnızca gerektiği kadar oda açarsınız (en az yetki). Bu ikisi bir araya geldiğinde, tek bir hesabın ele geçirilmesi artık tüm sitenin değil, yalnızca sınırlı bir alanın riski olur. Aynı mantık, güvenliği baştan doğru kurmanın neden ucuza geldiğini de gösterir: rolleri, hesapları ve erişimleri en başta doğru tasarlamak, sonradan onlarca hesabı tek tek toparlamaktan çok daha kolaydır.

Beş Temeli Bir Arada Düşünmek

Bu beş katman ayrı ayrı değil, bir bütün olarak değer üretir. HTTPS veriyi yolda korur; güncelleme bilinen açıkları kapatır; 2FA ve güçlü parola girişi kilitler; en az yetki bir ihlalin yayılma alanını daraltır; yedek ise her şey yanlış gittiğinde geri dönüş garantisidir. Bunları katmanlı savunma (defense in depth) olarak düşünmek doğru olur: bir katman aşılsa bile bir sonraki katman saldırganı durdurur veya yavaşlatır. Hiçbiri tek başına "tam güvenlik" sağlamaz, ama beşi birlikte uygulandığında, müşterilerimizde gördüğümüz gerçek dünya saldırılarının çok büyük bir kısmı daha ilk adımda durur. Üstelik bu temeller, ileri seviye önlemlere (WAF, CDN, güvenlik başlıkları, ileri loglama ve izleme) sağlam bir zemin de hazırlar.

Aşağıdaki özet, her temelin hangi riske karşı durduğunu ve OWASP Top 10:2025'teki karşılığını bir arada gösteriyor:

Önemli bir nokta: güvenlik tek seferlik bir kurulum değil, süreklilik isteyen bir bakım sürecidir. Bakımsız bırakılan bir site, bugün güvenli olsa bile birkaç ay sonra güncellenmemiş bir eklenti yüzünden açık hâle gelebilir. Bu yüzden güvenliği, sitenin düzenli bakım planının ayrılmaz bir parçası olarak kurgulamak gerekir; bu konuyu web sitesi yenileme rehberimizde ve genel web sitesi yapım rehberimizde bakım başlığı altında ayrıca işliyoruz.

Sitenizin bu temel güvenlik katmanlarının doğru kurulup kurulmadığından emin değilseniz veya yeni bir projeye güvenliği gün-1'den doğru kurarak başlamak istiyorsanız, özel yazılım ve web sitesi hizmetimiz kapsamında HTTPS, güncelleme disiplini, 2FA, en az yetki ve site dışı yedeklemeyi standart olarak kuruyoruz. Mevcut durumunuzu hızlıca değerlendirmek için ücretsiz analiz ve teklif sihirbazımızdan da yararlanabilirsiniz.

Web Sitesi Güvenliğinde En Sık Karşılaşılan Tehditler Nelerdir?

Web sitesi güvenliğinde tehditlerin büyük çoğunluğu üç kümede toplanır: uygulama katmanı açıkları (yetki kontrolü zaafları, yanlış yapılandırma, enjeksiyon), üçüncü taraf bileşen riskleri (özellikle WordPress eklenti ve temaları) ve otomatik saldırılar (bot, kaba kuvvet, DDoS). Sektörün ortak referans çerçevesi OWASP Top 10'dur; en güncel sürüm olan 2025 baskısı (8. baskı), 175.000'den fazla CVE analizine dayanır. Aşağıda bu üç tehdit kümesini ve form/giriş güvenliğini somut olarak açıyoruz. Güvenliğin neden artık zorunlu bir altyapı olduğunu ve HTTPS/SSL temelini web sitesi güvenliği rehberinin diğer bölümlerinde, altyapı tarafını ise domain, hosting ve SSL altyapı rehberinde ele alıyoruz.

Önce bu üç kümenin pratikte nasıl göründüğünü ve hangi savunmayla karşılandığını bir arada görmek, önceliklendirmeyi kolaylaştırır:

OWASP Top 10 Nedir, 2025 Sürümünde Ne Değişti?

OWASP (Open Worldwide Application Security Project) Top 10, web uygulamalarındaki en kritik güvenlik risklerinin periyodik olarak yayımlanan listesidir. Geliştirici ve ajanslar için fiilî bir öncelik haritası işlevi görür: hangi açık türlerinin gerçek dünyada en çok istismar edildiğini gösterir. Güncel sürüm 2025 baskısıdır ve 175.000'in üzerinde CVE (Common Vulnerabilities and Exposures — bilinen güvenlik açığı kaydı) analizine dayanır. Müşterilerimizde gördüğümüz pratik fayda şu: bu liste, "neyi önce kapatmalıyız?" sorusuna kanıta dayalı bir sıralama verir. Liste her birkaç yılda bir güncellenir; sıralamadaki yükseliş ve düşüşler, sahadaki tehdit ağırlığının nasıl kaydığını okumanın en sade yoludur.

2025 sürümündeki güncel sıralama şöyledir:

Bu sürümdeki en dikkat çekici değişiklikler şunlardır: Software Supply Chain Failures (A03) yeni bir başlık olarak listeye girdi — yani artık riskin önemli bir kısmı sizin yazdığınız koddan değil, kullandığınız paket, kütüphane ve eklentilerden geliyor. Security Misconfiguration #5'ten #2'ye yükseldi; bu, modern altyapıların (bulut, container, çok sayıda servis) karmaşıklaştıkça yanlış yapılandırmanın ne kadar yaygın bir kapı haline geldiğini gösterir. SSRF (Server-Side Request Forgery), A01 Broken Access Control'e konsolide edildi. Enjeksiyon (A05) başlığının altında ise hem SQL enjeksiyonu hem de XSS bulunur — bu iki klasik açık hâlâ gündemdedir.

Listeyi tek tek başlıklar olarak değil, birbirini besleyen bir zincir olarak okumak daha doğru bir bakış verir. Pratikte en sık karşılaştığımız senaryoları somutlaştıralım:

• A01 Broken Access Control: En tepede olması tesadüf değil. Klasik örnek, URL'deki bir kimlik numarasını değiştirerek başka kullanıcının siparişine/faturasına erişmektir (IDOR). Sunucu, "bu kaydı isteyen kişi gerçekten bu kaydın sahibi mi?" sorusunu her istekte sormazsa açık oluşur. SSRF'nin de bu başlığa konsolide edilmesi, "sunucunun adına yetkisiz istek yaptırma"nın da temelde bir yetki sorunu olduğunu vurgular.
• A02 Security Misconfiguration: Açık bırakılmış yönetim panelleri, üretim ortamında açık kalan hata ayıklama (debug) modu, dizin listelemesinin açık olması, varsayılan parolayla gelen servisler. Kod kusursuz olsa bile yanlış bir ayar tek başına kapı açabilir.
• A05 Injection: Kullanıcı girdisinin doğrudan veritabanı sorgusuna ya da HTML çıktısına karışması. SQL enjeksiyonunda saldırgan veritabanını okur/değiştirir; XSS'te ise ziyaretçinin tarayıcısında zararlı betik çalıştırır (örneğin oturum çerezini çalmak için).
• A09 Logging/Monitoring: Diğer başlıklardan farklı olarak doğrudan bir "açık" değil, bir körlüktür. Saldırı kayıt altına alınmıyorsa, ihlal genellikle aylar sonra fark edilir; o noktada hem teknik hem hukuki maliyet katlanır.

Bu listeyi pratiğe dökmenin en kestirme yolu, güvenliği tasarım aşamasında (A06 Insecure Design'ı önlemek) ele almaktır. Yani güvenlik, site bittikten sonra eklenen bir katman değil, UI/UX ve mimari kararların içinde düşünülmesi gereken bir ilkedir. Sonradan eklenen güvenlik genellikle yama mantığıyla çalışır ve her yamada bir boşluk kalma ihtimali artar; baştan tasarlanan güvenlik ise varsayılan davranışı güvenli kılar. Bu yüzden bizde her özel yazılım projesinde güvenlik, baştan kapsamın parçasıdır; konuyu özel yazılım hizmetimiz sayfasında ayrıca anlatıyoruz.

WordPress Eklenti ve Tema Riski Neden Bu Kadar Büyük?

WordPress, tüm web sitelerinin yaklaşık %41,9'unu, CMS kullanan sitelerin ise %59,5'ini çalıştırır (Haziran 2026, W3Techs). Bu yaygınlık iki sonuç doğurur: bir yandan devasa bir ekosistem (60.000'den fazla eklenti, 10.000'den fazla tema), diğer yandan saldırganlar için çok geniş ve cazip bir hedef yüzeyi. WordPress'in en yakın rakibi tüm web payında Shopify %5,2, ardından Wix %4,3 olduğuna göre, WordPress en yakın rakibinin yaklaşık 9 katı büyüklükte bir kitleye sahiptir — bot ve otomatik saldırı araçları doğal olarak en çok bu platforma yöneliktir. Saldırgan açısından mantık basittir: tek bir popüler eklentide bulunan bir açık, aynı eklentiyi kullanan on binlerce siteye birden uygulanabilir. Bu yüzden yaygın bir bileşendeki açık, niş bir bileşendeki açıktan çok daha hızlı ve ölçekli istismar edilir.

Burada kritik bir yanlış anlamayı düzeltelim: WordPress çekirdeğinin kendisi genellikle riskin kaynağı değildir. Müşterilerimizde gördüğümüz açıkların büyük çoğunluğu, güncellenmemiş veya terk edilmiş üçüncü taraf eklentiler ve temalardan ve zayıf yönetici (admin) parolalarından kaynaklanır. OWASP 2025'in yeni A03 Software Supply Chain Failures başlığı tam da bu durumu çerçeveler: kullandığınız her eklenti, sitenize başka birinin kodunu dahil etmektir ve o kod açık içeriyorsa risk sizindir. Bu, "ücretsiz eklenti = maliyetsiz" yanılgısının neden tehlikeli olduğunu da açıklar — eklentinin görünmeyen maliyeti, ona yüklediğiniz güven ve sürdürdüğünüz bakım yüküdür.

Eklenti/tema riskini pratikte yönetmek için izlediğimiz somut adımlar şunlardır:

• Güncel tutun. CMS çekirdeği, tema ve eklentiler düzenli güncellenmeli. Bilinen açıkların (CVE) çoğu, güncellenmemiş bileşenlerden sömürülür. Otomatik güncelleme mümkün olduğunca açılmalı, kritik güncellemeler önce staging (deneme) ortamında denenmeli ki bir güncelleme siteyi bozarsa canlıda fark edilmesin.
• Yüzey alanını küçültün. Kullanılmayan her eklenti ve tema, denenmese bile saldırı yüzeyini büyütür; çünkü deaktive edilmiş bir bileşenin dosyaları sunucuda durmaya devam eder ve bazı açıklar eklenti pasifken bile sömürülebilir. Aktif kullanmadığınız bileşenleri pasifleştirmek yetmez — tamamen silin.
• Güvenilir kaynak seçin. Aktif geliştirilen, son güncelleme tarihi yakın, kurulu site sayısı yüksek ve değerlendirmesi iyi eklentileri tercih edin. Bir yıldır güncellenmemiş bir eklenti, pratikte terk edilmiş demektir ve gelecekteki CVE'lere yama almayacaktır. "Nulled" (kırılmış/lisanssız) tema ve eklentilerden kesinlikle uzak durun; bunlar sık sık içine gizlenmiş arka kapı (backdoor) ile dağıtılır.
• Admin hesabını sertleştirin. Güçlü, benzersiz parola + iki faktörlü doğrulama (2FA) zorunlu olmalı. Yönetici kullanıcı adı "admin" olmamalı; gereksiz yönetici hesapları kaldırılmalı. Her kullanıcıya işini yapmaya yetecek en düşük yetki verilmeli (en az ayrıcalık ilkesi) — içerik girecek bir editöre tam yönetici yetkisi vermek gereksiz bir risktir.

Bu yük tam da hazır CMS ile özel yazılım arasındaki farkın somutlaştığı noktadır. Güvenlik sorumluluğu seçtiğiniz altyapıya göre kayar; kararı verirken bu sorumluluğun kimde olduğunu bilmek gerekir:

Görüldüğü gibi WordPress, kontrolü size verirken sorumluluğu da size yükler; hazır kurucu bakımı devralır ama esnekliği kısar; özel yazılım yüzeyi en dar tutma imkânı sunar ama düzenli bağımlılık bakımı gerektirir. Bu kararı verirken bakım yükünü baştan hesaba katmak gerekir; konuyu hangi CMS seçilmeli rehberinde ve hazır site mi özel yazılım mı karşılaştırmasında ayrıntılı işliyoruz.

Bot, Kaba Kuvvet ve DDoS Saldırılarına Karşı Ne Yapılır?

Modern bir web sitesine gelen trafiğin önemli bir kısmı insan değil, otomatik botlardır. Bunların bir bölümü zararsızdır (arama motoru tarayıcıları gibi), bir bölümü ise aktif olarak zararlıdır: giriş ekranlarına sürekli parola deneyen kaba kuvvet (brute-force) botları, açık tarayan otomatik araçlar, içerik kazıyan scraper'lar ve sunucuyu hizmet veremez hale getirmeyi amaçlayan DDoS (dağıtık hizmet engelleme) saldırıları. Bu tehditlerin ortak özelliği otomatik ve ölçekli olmalarıdır; dolayısıyla savunma da otomatik ve katmanlı olmalıdır. Tek bir kişinin elle saldırması nadirdir; gerçek tehdit, yorulmadan ve binlerce IP'den aynı anda deneme yapabilen yazılımdır.

Bu üç saldırı tipinin amacı ve karşı önlemi birbirinden farklıdır; ayırt etmek doğru savunmayı seçmeyi kolaylaştırır:

Bu kategoride en etkili savunma kombinasyonu WAF + CDN ikilisidir. Web Application Firewall (WAF), bilinen saldırı kalıplarını (enjeksiyon denemeleri, kötü amaçlı istekler) istek sunucuya ulaşmadan filtreler. CDN (içerik dağıtım ağı; örneğin Cloudflare) ise hem coğrafi olarak dağıtık altyapısıyla DDoS trafiğini emer ve azaltır, hem de bot trafiğini ayırarak meşru ziyaretçilere hız kazandırır. Bu katman aynı zamanda Core Web Vitals tarafında da kazanç sağlar; edge/CDN, LCP gibi hız metrikleri için zaten kritiktir — performans ile güvenlik bu noktada örtüşür. Yani doğru kurgulanan bir CDN/WAF katmanı tek yatırımla iki sorunu birden çözer: hem saldırıyı süzer hem siteyi hızlandırır. Hız tarafını ayrıca site hızı ve Core Web Vitals rehberinde anlatıyoruz.

Bot ve otomatik saldırılara karşı pratik önlemler:

• Rate-limit (hız sınırlama): Aynı IP'den belirli sürede yapılabilecek giriş/istek sayısını sınırlayın. Bu, kaba kuvvet saldırılarını büyük ölçüde işlevsiz kılar; çünkü saldırı ekonomik olmaktan çıkar — saniyede binlerce deneme yerine dakikada birkaç denemeyle parola kırmak pratikte imkânsızdır.
• WAF + CDN: Cloudflare gibi bir katman, kötü trafiği ve botu filtreler, DDoS'u azaltır, yaygın saldırı kalıplarını engeller. Köken (origin) sunucunuzun gerçek IP'sini gizleyerek doğrudan hedef alınmasını da zorlaştırır.
• Giriş ekranını koruyun: Yönetici giriş yolunu varsayılan bırakmamak, başarısız giriş denemelerini sınırlamak ve şüpheli IP'leri geçici engellemek botların işini zorlaştırır. CAPTCHA gibi insan doğrulaması, otomatik form gönderimini büyük ölçüde keser.
• İzleme ve loglama: OWASP A09 (Security Logging and Monitoring Failures) tam da bu eksikliğe işaret eder — saldırı fark edilemezse durdurulamaz. Anormal trafik artışlarını, tekrarlayan başarısız girişleri kayıt altına alın ve uyarı kurun. Erken uyarı, başarılı bir ihlal ile zamanında durdurulan bir deneme arasındaki farktır.

Form ve Giriş (Login) Güvenliği Nasıl Sağlanır?

Bir web sitesinin en çok istismar edilen noktaları, kullanıcı girdisi kabul eden yerlerdir: iletişim formları, üyelik/giriş ekranları, arama kutuları, yorum alanları ve e-ticaret ödeme akışları. Buralar hem enjeksiyon (A05) hem de kimlik doğrulama (A07) açıkları için doğal hedeftir. Sebebi basittir: bu noktalar, dışarıdan gelen verinin sizin sisteminizin içine girdiği kapılardır; kapıdan geçen her şey güvenilmez kabul edilmeli ve doğrulanmalıdır. İyi haber şu: bu noktaları korumanın kuralları nettir ve büyük ölçüde standartlaşmıştır.

Güvenli form ve giriş için olmazsa olmazlar:

• Sunucu tarafı doğrulama: Girdi doğrulaması yalnızca tarayıcıda (istemci tarafında) yapılmamalı; saldırgan, tarayıcıyı atlayıp doğrudan sunucuya istek göndererek istemci kontrollerini kolayca aşabilir. Tarayıcı doğrulaması kullanıcı deneyimi içindir; asıl güvenlik doğrulaması mutlaka sunucuda yapılır.
• Girdi temizleme (sanitization) ve çıktı kodlama: Tüm kullanıcı girdileri, enjeksiyon ve XSS'i (A05) önlemek için temizlenip kodlanmalı. Veritabanı sorgularında string birleştirme yerine parametreli (prepared) sorgular kullanılmalı — bu, SQL enjeksiyonunu kökten engelleyen en etkili tekniktir. Ekranda gösterilen kullanıcı içeriği ise HTML olarak kodlanmalı ki betik olarak çalışmasın.
• CSRF token: Form gönderimlerinde Cross-Site Request Forgery'yi önlemek için her oturuma özel, tahmin edilemez token kullanılmalı. Bu, kullanıcının başka bir sitedeyken farkında olmadan sizin sitenizde işlem yaptırılmasını engeller.
• Rate-limit: Giriş ve form denemelerine hız sınırı koyarak kaba kuvvet saldırılarını ve spam gönderimlerini engelleyin.
• Güçlü parola + 2FA: Zayıf ve tekrar kullanılan parolalar, kimlik doğrulama hatalarının (A07) ana kaynağıdır. Güçlü parola politikası ve iki faktörlü doğrulama, parola sızsa bile hesabın ele geçirilmesini ciddi biçimde zorlaştırır. Parolalar veritabanında asla düz metin tutulmamalı; modern bir özümleme (hashing) algoritmasıyla saklanmalı.
• Oturum güvenliği: Oturum çerezleri güvenli (Secure, HttpOnly) işaretlenmeli, oturumlar makul bir süre sonra zaman aşımına uğramalı, çıkışta gerçekten sonlandırılmalı. Giriş sonrası oturum kimliği yenilenmeli ki çalınan eski bir kimlik işe yaramasın.

Burada Türkiye bağlamında kritik bir hukuki boyut da var. KVKK (6698 sayılı kanun), kişisel veri işleyen sitelerde "veri güvenliği" teknik ve idari tedbirlerini yasal bir zorunluluk haline getirir (KVKK m.12). Yani bir iletişim ya da üyelik formu üzerinden ad, e-posta, telefon gibi kişisel veri topladığınızda; HTTPS ile şifreli iletim, verinin korunması, erişim kontrolü, log tutma ve veri ihlali halinde bildirim yükümlülükleri devreye girer. Bu çerçevede bir güvenlik açığı sadece teknik değil, aynı zamanda hukuki bir risktir — bir veri ihlali, Kurul'a ve etkilenen ilgili kişilere bildirim yükümlülüğü doğurur. Üstelik formun yanında doğru yasal metinlerin bulunması da uyumun parçasıdır: aydınlatma metni ile açık rıza/ticari ileti izni ayrı ayrı düzenlenmeli, tek bir "kabul ediyorum" kutusunda birleştirilmemelidir. Form güvenliğini bu yüzden hem teknik hem de uyum (compliance) açısından ele almak gerekir; kurumsal sitelerdeki yasal metin ve veri akışı gereksinimlerini kurumsal web sitesi rehberinde, B2B tarafındaki lead formu güvenliği ve sürtünme dengesini ise B2B web sitesi rehberinde ayrıca işliyoruz.

Sitenizin hangi altyapıda çalıştığını ve teknolojik parmak izini hızlıca görmek için e-ticaret altyapı tespit aracımızı kullanabilir; mevcut sitenizin güvenlik, performans ve uyum açısından durumunu kapsamlı değerlendirmek için ise ücretsiz site analizi talebinde bulunabilirsiniz. Yetki kontrolünden (A01) eklenti hijyenine, form güvenliğinden bot savunmasına kadar bu bölümde anlattığımız tehditlerin tamamı, doğru kurgulandığında yönetilebilir risklerdir — kritik olan, bunları sonradan yamamak yerine baştan tasarımın parçası yapmaktır. Güvenlik bir kez kurulup bırakılacak bir özellik değil, güncelleme, izleme ve düzenli yedeklemeyle sürdürülen bir süreçtir.

KVKK ve veri güvenliği yükümlülüğü: web sitesi sahibi için ne anlama geliyor?

Kısa cevap: Türkiye'de kişisel veri işleyen her web sitesi, KVKK (6698 sayılı Kişisel Verilerin Korunması Kanunu) karşısında "veri sorumlusu"dur ve sitesinde teknik/idari güvenlik tedbirleri almak yasal bir zorunluluktur, iyi niyetli bir tercih değil. KVKK m.12, veri sorumlusunu kişisel verilerin hukuka aykırı işlenmesini ve verilere yetkisiz erişimi önlemek, verileri muhafaza etmek için "uygun güvenlik düzeyini sağlamaya yönelik gerekli her türlü teknik ve idari tedbiri" almakla yükümlü tutar. Yani bir iletişim formundan tek bir e-posta adresi topluyorsanız bile, o veriyi koruyacak güvenlik altyapısından hukuken sorumlusunuz.

Burada kritik nokta şu: web güvenliği ve veri koruma uyumu, Türkiye'de iki ayrı dünya değil, iç içe geçmiş tek bir sorumluluktur. Bir güvenlik açığından veri sızarsa, bu yalnızca teknik bir arıza değil aynı zamanda hukuki bir ihlal doğurur. Bu yüzden web sitesi güvenliği konusunu Türkiye bağlamında düşünürken HTTPS, form koruması ve sunucu yapılandırması kadar KVKK uyumunu da aynı masaya koymak gerekiyor. Müşterilerimizde gördüğümüz en sık hata, "güvenlik" ile "yasal uyum"u ayrı projeler gibi ele alıp ikisini de yarım bırakmaktır. Oysa pratikte bu ikisi tek bir mimari kararla birlikte çözülür: doğru kurgulanmış bir altyapı, hem saldırı yüzeyini daraltır hem de Kurul'un beklediği "uygun güvenlik düzeyi"ni belgelenebilir kılar.

Bu sorumluluğun bir de "kim için geçerli" boyutu var. Yaygın bir yanılgı, KVKK'nın yalnızca büyük şirketleri veya e-ticaret sitelerini ilgilendirdiğidir. Gerçekte tek bir iletişim formu, bülten kayıt alanı, randevu formu ya da yorum bölümü bile kişisel veri (ad, e-posta, telefon, IP) topladığı için siteyi "veri sorumlusu" konumuna sokar. Tek kişilik bir danışmanın kişisel sitesinden büyük bir kurumsal portala kadar herkes aynı m.12 yükümlülüğüne tabidir; fark, toplanan verinin hacmi ve hassasiyetiyle orantılı olarak alınması beklenen tedbirin derinliğindedir.

KVKK m.12 pratikte hangi teknik tedbirleri zorunlu kılıyor?

KVKK'nın veri güvenliği yükümlülüğü soyut bir "dikkatli olun" çağrısı değildir; Kurul'un rehberleri ve kararlarıyla somut beklentilere dönüşmüştür. Bir web sitesi için en doğrudan karşılığı olan teknik tedbirler şunlardır:

• Şifreli iletişim (HTTPS/TLS): Site ile ziyaretçi arasındaki tüm trafik şifrelenmeli. KVKK açısından bu, "aktarım sırasında verinin korunması"nın temel şartıdır; özellikle form, üyelik veya ödeme verisi taşıyan sayfalarda olmazsa olmaz.
• Erişim kontrolü: Yönetim paneline, veritabanına ve sunucuya kimlerin eriştiği sınırlandırılmalı; güçlü parola ve iki faktörlü doğrulama (2FA) uygulanmalı. Her çalışanın admin yetkisi olması KVKK açısından da güvenlik açısından da risktir.
• Şifreleme: Hassas kişisel veriler (özellikle özel nitelikli veriler) veritabanında açık metin değil şifreli saklanmalı.
• Loglama (kayıt tutma): Sisteme erişimlerin ve veri işleme hareketlerinin kayıt altına alınması; bir ihlal halinde "ne oldu, ne zaman oldu" sorusunu yanıtlayabilmek için gerekli.
• Veri ihlali bildirimi altyapısı: Bir veri ihlali yaşandığında Kurul'a ve ilgili kişilere bildirim yapma yükümlülüğü vardır; bunu yapabilmek için önce ihlali fark edecek izleme/log sisteminin kurulu olması gerekir.

Bu tedbirlerin teknik karşılığı, uluslararası güvenlik standartlarıyla birebir örtüşür. Özellikle OWASP Top 10:2025 (175.000'den fazla CVE analizine dayanan 8. baskı) ile KVKK m.12 arasındaki örtüşme şaşırtıcı derecede yüksektir. Aşağıdaki tablo, en sık karşılaştığımız OWASP risk başlıklarının KVKK'daki hukuki karşılığını ve web sitesi düzeyinde somut çözümünü gösteriyor:

Tablonun verdiği mesaj nettir: OWASP'a göre sağlam bir site kurmak, çoğu durumda KVKK'nın teknik tedbir beklentisini de büyük ölçüde karşılar. Tersi de geçerlidir — OWASP listesinin ilk iki sırasındaki zafiyetler (yetki kontrolü ve yapılandırma hataları) aynı zamanda KVKK ihlallerinin de en sık teknik kökenidir. Bu iki dünyayı birlikte ele almak için web güvenliği temellerini ve altyapı/CMS seçimini proje başında planlamak gerekir; çünkü güncellenmemiş üçüncü taraf eklentiler (WordPress'te en yaygın açık kapı) hem teknik hem hukuki risk üretir. WordPress'in tüm web sitelerinin yaklaşık %41,9'unu çalıştırdığı düşünülürse (2026 Haziran, W3Techs), bu eklenti yüzeyinin ne kadar büyük bir saldırı zemini oluşturduğu daha iyi anlaşılır.

İdari tedbirler: sadece kod yetmez

KVKK uyumu yalnızca sunucu ve kod düzeyinde bitmez; idari (organizasyonel) tedbirler de zorunludur. Web sitesi sahipleri açısından pratik karşılıkları:

• Aydınlatma yükümlülüğü: Kişisel veri toplayan her noktada (iletişim formu, üyelik, bülten kaydı, çerez) ziyaretçi; hangi verinin, hangi amaçla, ne kadar süre işlendiği konusunda bilgilendirilmeli. Kurul'un 2026 yorumuyla aydınlatma artık tek seferlik bir "doküman" değil, sürekli işleyen bir "süreç" olarak değerlendiriliyor.
• VERBİS kaydı: Belirli eşikleri aşan veri sorumlularının Veri Sorumluları Sicili'ne (VERBİS) kayıt yükümlülüğü vardır.
• Veri işleyen sözleşmeleri: Hosting sağlayıcısı, e-posta servisi, analitik aracı gibi üçüncü taraflar "veri işleyen" konumundadır; onlarla veri güvenliği taahhüdü içeren sözleşmeler yapılmalıdır.
• Saklama ve imha: Veriler süresiz tutulamaz; saklama süresi dolan veriler için periyodik imha politikası gerekir.

Bu idari tedbirlerin web sitesi mimarisine yansıyan, sıkça gözden kaçan bir boyutu da yurt dışına veri aktarımıdır. Sitenizde Google Analytics, Meta Pixel, bir ABD merkezli e-posta servisi ya da yurt dışı bulut barındırma kullanıyorsanız, kişisel veriyi büyük olasılıkla yurt dışına aktarıyorsunuz demektir; bu aktarım KVKK'nın aktarım kurallarına tabidir ve aydınlatma metninizde açıkça belirtilmelidir. Yerli ve yurt dışı barındırma kararı bu açıdan yalnızca bir hız tercihi değil, aynı zamanda bir uyum tercihidir. Yurt içi barındırma TR ziyaretçiye düşük gecikme ve veri yerelleştirme algısı sağlarken, modern global CDN (Cloudflare, Vercel edge gibi) ile yurt dışı barındırma da Türkiye'ye hızlı sunabilir; ancak ikinci senaryoda aktarım yükümlülüklerini doğru yönetmek gerekir. Altyapı kararlarının bu yasal boyutunu domain, hosting ve SSL rehberimizde ayrıca ele alıyoruz.

Bu çerçevede özellikle kurumsal ve B2B sitelerinde, lead toplayan formlar ve teklif talepleri kişisel veri içerdiği için aydınlatma metni ve açık rıza yönetimi tasarımın bir parçası olmalıdır. B2B'de dönüşümün genelde "satın al" değil "teklif iste / demo planla / iletişime geç" olduğunu hatırlarsak, en değerli verinin tam da bu form anında toplandığı görülür — yani uyum, doğrudan dönüşüm noktasında devreye girer. Konuyu detaylı kurgulamak isteyenler için kurumsal web sitesi ve B2B site tasarımı rehberlerimizde bu yasal metinlerin sayfa mimarisine nasıl yerleştirileceğini ele alıyoruz.

Aydınlatma metni ile açık rıza neden ayrı olmalı?

Türkiye uygulamasında sık yapılan ve cezalandırılan bir hata var: aydınlatma metni ile açık rıza/ticari ileti iznini tek bir kutuda birleştirmek. KVKK Kurulu'nun KVKK'nın güncel İlke Kararı bu ayrımı net biçimde pekiştirdi. İki kavramın hukuki niteliği temelden farklıdır:

Pratik sonuç: form altına "Aydınlatma metnini okudum ve ticari ileti almayı kabul ediyorum" şeklinde tek bir işaret kutusu koymak hukuken sakıncalıdır. Doğru tasarım, aydınlatma metnini bir bilgilendirme bağlantısı/metni olarak sunmak; ticari ileti veya pazarlama rızasını ise varsayılan olarak işaretsiz, ayrı ve isteğe bağlı bir onay kutusu olarak konumlandırmaktır. "Zorunlu olmayan onayların önceden işaretli gelmesi" de açık rıza ilkesine aykırıdır; çünkü açık rıza özgür iradeyle verilmelidir, kullanıcı bir kutunun işaretini kaldırarak rızadan kaçınmak zorunda bırakılamaz.

Bu detay aslında bir UX kararıdır; formun dönüşümünü düşürmeden yasaya uymak için UI/UX tasarım ilkelerini bu yasal kısıtlarla birlikte düşünmek gerekir. Burada sık dile getirilen "ekstra onay kutusu dönüşümü düşürür" kaygısı çoğu zaman yersizdir: ayrı, şeffaf ve baskısız bir onay akışı kullanıcıya kontrol hissi ve güven verdiği için, iletişime geçme oranını çoğunlukla düşürmez, sürtünmeyi azaltarak artırabilir. Üstelik açık rızayla toplanan bir pazarlama izni, sonradan geri dönüş oranı yüksek, "temiz" bir lead listesi anlamına gelir — yani uyum, uzun vadede pazarlama kalitesini de yükseltir. Formun kendisini dönüşüm odaklı kurgulamak için dönüşüm odaklı landing page rehberimiz ile bu yasal disiplini birlikte uygulamak en sağlıklı yaklaşımdır.

Çerez (cookie) uyumu nasıl sağlanır?

Çerez yönetimi, KVKK uyumunun en görünür ve en sık denetlenen ayağıdır. Kurul, çerez aydınlatma ve rıza eksikliğine fiilen ceza vermiştir; bu nedenle "herkes koyuyor, gerek yok" yaklaşımı risklidir. Doğru bir çerez kurgusu şunları içerir:

• Çerez bandı (banner): Siteye ilk girişte görünen, çerez kullanımını bildiren ve seçim sunan bir bilgilendirme alanı.
• Çerez politikası sayfası: Hangi çerezlerin, hangi amaçla, ne kadar süre kullanıldığını açıklayan ayrı bir doküman.
• Kategori bazlı rıza: Sitenin çalışması için zorunlu çerezler rıza gerektirmez; ancak analitik ve pazarlama (örneğin reklam izleme) çerezleri için açık rıza alınmalıdır. Bu rıza, çerezler yüklenmeden önce alınmalı ve kullanıcı reddedebilmelidir.
• Reddi de mümkün kılma: "Kabul et" kadar görünür bir "reddet/yönet" seçeneği sunmak; yalnızca "kabul" butonu olan bandlar uyumlu sayılmaz.

Çerez kategorilerini netleştirmek, hem doğru rıza akışı kurmak hem de gereksiz script yükünü kontrol etmek için faydalıdır. Tipik bir sitede çerezler şöyle ayrışır:

Teknik açıdan dikkat: analitik ve pazarlama scriptlerini (Google Analytics, Meta Pixel vb.) rıza alınmadan tetiklememek gerekir. Bu yalnızca bir uyum kuralı değil, aynı zamanda bir performans avantajıdır. Gereksiz üçüncü taraf script erkenden yüklenirse hem yasa ihlali doğar hem de Core Web Vitals bozulur: ağır izleme scriptleri ana iş parçacığını meşgul ederek INP'yi (Interaction to Next Paint, iyi eşik 200 ms altı) geciktirir; render'ı bloke eden scriptler LCP'yi (iyi eşik 2,5 sn altı) yavaşlatır. Yani "rıza alınana kadar tetikleme" yaklaşımı, çoğu ziyaretçi için izleme scriptlerinin ilk yükte hiç çalışmaması anlamına gelir — bu da CWV'ye doğrudan iyi yansır. Sitenizin ne kadar üçüncü taraf izleme barındırdığını ve altyapı sinyallerini görmek için GEO denetim aracımızı, hangi teknolojiler üzerinde çalıştığınızı tespit etmek için ise altyapı tespit aracımızı kullanabilirsiniz.

SSL/HTTPS: "güvenli değil" uyarısının ötesinde

SSL/TLS sertifikası artık opsiyonel değil zorunlu bir temeldir ve algı düzeyinde çoğu zaman hafife alınır. Üç ayrı düzlemde önemlidir:

• Teknik: HTTPS tüm trafiği şifreler, sunucunun kimliğini doğrular ve veri bütünlüğünü sağlar. "SSL" terimi yaygın kullanılsa da teknik olarak güncel protokol TLS'tir (TLS 1.2/1.3).
• Hukuki (KVKK): Form veya üyelik üzerinden kişisel veri toplayan bir sitede HTTPS'in olmaması, KVKK m.12'nin "aktarım güvenliği" beklentisini doğrudan ihlal eder. Yani SSL eksikliği yalnızca tarayıcı uyarısı değil, potansiyel bir veri güvenliği ihlalidir.
• SEO ve güven algısı: HTTPS bir Google sıralama sinyalidir ve tarayıcıların adres çubuğundaki "güvenli değil" uyarısını önler. Ziyaretçinin formu doldurmadan terk etmesinin en sessiz nedenlerinden biri bu uyarıdır.

İyi haber: Let's Encrypt ile ücretsiz sertifika alınabilir ve modern hosting/edge platformları (Vercel, Netlify, Cloudflare gibi) bunu otomatik sağlar. Yani SSL bugün bir maliyet kalemi olmaktan çıkmış, sadece bir yapılandırma adımına dönüşmüştür. Ancak "sertifika var" demek "doğru kurulmuş" demek değildir; sık karşılaştığımız eksikler arasında HTTP'den HTTPS'e kalıcı (301) yönlendirmenin yapılmaması, "karışık içerik" (mixed content — HTTPS sayfada HTTP üzerinden yüklenen görsel/script) ve HSTS başlığının tanımlanmaması yer alır. Karışık içerik, sayfanın bir kısmını şifresiz bıraktığı için tarayıcıda güven göstergesini bozar ve bazı kaynakların hiç yüklenmemesine yol açabilir. Sertifika ve alan adı altyapısını uçtan uca kurmak için domain, hosting ve SSL rehberimiz başvuru kaynağı olabilir; alan adı tarafında ise marka koruması için hem .com hem .com.tr almak yaygın bir tercih olduğundan, başlangıç araştırmasını domain sorgulama aracımızla yapabilirsiniz.

Form ve giriş güvenliği: spam, kaba kuvvet ve veri sızıntısı

Formlar, bir web sitesinin hem en değerli dönüşüm noktası hem de en sık saldırıya uğrayan yüzeyidir. KVKK açısından da kritiktir; çünkü kişisel veri tam burada toplanır. Güvenli bir form/giriş akışı için olmazsa olmazlar:

• Sunucu tarafı doğrulama: Girdiler yalnızca tarayıcıda değil, mutlaka sunucuda da doğrulanmalı. İstemci tarafı doğrulama atlatılabilir.
• Girdi temizleme (sanitization): SQL injection ve XSS gibi saldırıları önlemek için kullanıcı girdisi temizlenmeli/kaçırılmalı. Bu, OWASP Top 10:2025'te A05 Injection başlığının doğrudan konusudur.
• CSRF token: Form gönderimlerinde sahte istek (cross-site request forgery) saldırılarına karşı token kullanımı.
• Rate-limit (hız sınırı): Aynı IP'den dakikada onlarca giriş/form denemesi engellenmeli; bu, kaba kuvvet (brute force) ve spam saldırılarını kırar.
• Güçlü parola + 2FA: Özellikle yönetim girişlerinde iki faktörlü doğrulama, çalınmış parolaların tek başına işe yaramamasını sağlar.

Bu noktada CAPTCHA tartışmasına değmek gerekir. CAPTCHA (veya görünmez alternatifleri) bot ve spam trafiğini azaltmakta etkilidir; ancak iki yönlü ele alınmalıdır. Bir yandan formu otomatik saldırılardan korur, diğer yandan kötü kurgulanırsa kullanılabilirlik ve erişilebilirlik engeli yaratır. Bu çelişki, WCAG 2.2 ile gelen SC 3.3.8 Accessible Authentication (erişilebilir kimlik doğrulama) kriteriyle de doğrudan ilgilidir: kullanıcıdan bilişsel bulmaca çözmesini isteyen (çarpık harfleri okuma, resim seçme gibi) doğrulama yöntemleri, alternatifi sunulmadığında bu kriteri ihlal edebilir. Pratik önerimiz: agresif, görsel-bulmaca CAPTCHA yerine arka planda çalışan, kullanıcıyı yormayan görünmez doğrulama veya basit "honeypot" (gizli tuzak alan — botların doldurduğu, gerçek kullanıcının görmediği alan) tekniklerini rate-limit ile birlikte kullanmak. Böylece hem spam azalır hem de gerçek kullanıcının form akışı bozulmaz, hem de erişilebilirlik korunur. WCAG 2.2'nin (5 Ekim 2023'te resmî W3C Recommendation oldu, ISO/IEC 40500:2025) bu beklentisini ve erişilebilir doğrulamanın nasıl kurgulanacağını web erişilebilirliği rehberimizde daha ayrıntılı işliyoruz.

Bir başka sık atlanan nokta: form gönderildikten sonra verinin nereye gittiğidir. E-posta ile düz metin olarak gönderilen form yanıtları, şifresiz bir kanaldan akıyorsa risk taşır. Tercih edilen kurgu, verinin şifreli bir veritabanına ya da güvenli bir panele düşmesi; e-posta bildiriminin ise yalnızca "yeni başvuru var" tetikleyicisi olmasıdır. Bu yaklaşım aynı zamanda KVKK'nın "saklama ve imha" disiplinini de kolaylaştırır: veri tek bir kontrollü yerde tutulduğunda, saklama süresi dolduğunda silmek de mümkün olur — onlarca e-posta kutusuna dağılmış kopyaları geri çağırmak ise imkânsızdır. Kurumsal e-posta altyapısını sağlam kurmak ve bildirim e-postalarının kendi alan adınızdan, kimliği doğrulanmış (SPF/DKIM) biçimde gitmesini sağlamak için kurumsal e-posta rehberini inceleyebilirsiniz.

Sürekli güncelleme ve yedekleme: ihmal en büyük açık kapı

Güvenlik tek seferlik bir kurulum değil, süreklilik gerektiren bir süreçtir; KVKK'nın "uygun güvenlik düzeyini sürdürme" beklentisi de bunu içerir. Sahada gördüğümüz veri ihlallerinin büyük kısmı sıfırıncı gün açıklarından değil, aylardır yamalanmamış bileşenlerden kaynaklanır:

• Güncelleme disiplini: CMS çekirdeği, tema ve eklentiler düzenli güncellenmeli. Bilinen açıkların (CVE) çoğu güncellenmemiş üçüncü taraf bileşenlerden sömürülür. OWASP Top 10:2025'e yeni eklenen A03 Software Supply Chain Failures tam olarak bu tedarik zinciri riskini öne çıkarır.
• Kullanılmayanı sil: Aktif olmasa bile yüklü duran eski eklenti/tema saldırı yüzeyidir. WordPress'te terk edilmiş üçüncü taraf eklentiler en büyük tek risk kalemidir.
• Yedekleme: Düzenli, otomatik, sürümlü ve site dışı (off-site) yedek alınmalı; geri yükleme periyodik olarak test edilmeli. Bir fidye yazılımı ya da saldırı sonrası tek gerçek kurtarma yolu, çalışan bir yedektir.
• WAF + CDN: Cloudflare gibi bir Web Uygulama Güvenlik Duvarı (WAF) ve CDN katmanı, kötü niyetli trafiği ve botları filtreler, DDoS'u azaltır, yaygın saldırı kalıplarını sınırda durdurur.

Yedekleme konusunda en sık yapılan hata, yedeğin "alındığını varsaymak" ama hiç geri yükleme testi yapmamaktır. İhtiyaç anında bozuk ya da eksik çıkan bir yedek, hiç olmayan yedekten daha tehlikelidir çünkü yanlış bir güven hissi verir. Bu yüzden yedekleme politikasının üç bileşeni de denetlenmelidir: yedeğin düzenli alındığı (otomasyon), site dışında tutulduğu (sunucu ele geçirilse bile erişilebilir) ve geri yüklenebildiği (periyodik tatbikat). Benzer şekilde, platform tercihinin bakım yükünü doğrudan etkilediğini de hatırlamak gerekir: hazır site kurucularda altyapı bakımı sağlayıcıdadır, WordPress'te güncelleme sorumluluğu tamamen sitenizdedir, özel yazılımda ise kontrol sizdedir ama disiplin de sizden beklenir. Bu denge, projenin başında hazır site mi özel yazılım mı kararıyla şekillenir.

Bu disiplini kuran ekiplerde fark belirgindir: bakımı sürdürülen bir site hem KVKK uyumunu korur hem de SEO ve performansını yitirmez. Bakımsız site ise hem güvenlik hem arama görünürlüğü açısından sessizce değer kaybeder; güncellenmeyen bileşenler bir gün bilinen bir CVE üzerinden ele geçirildiğinde, sonuç hem teknik bir olay hem de Kurul'a bildirilmesi gereken bir veri ihlali olur. Mevcut sitenizin altyapısının güncel ve güvenli olup olmadığından emin değilseniz, altyapı tespit aracımızla hangi teknolojiler üzerinde çalıştığınızı görebilir, bütünsel bir güvenlik ve uyum değerlendirmesi için ücretsiz analiz formumuz üzerinden başvurabilirsiniz. Kapsamlı kurulum, KVKK uyumlu form altyapısı ve güvenli özel geliştirme tarafında ise özel yazılım ve web geliştirme hizmetimizle, dönüşüm odaklı ve erişilebilir arayüz tarafında da web ve mobil UI/UX tasarım hizmetimizle uçtan uca destek veriyoruz.

Veri ihlali yaşandığında ne olur?

En sağlam kurguda bile sıfır risk yoktur; bu yüzden KVKK uyumunun bir de "ihlal sonrası" boyutu vardır. Kişisel verilere yetkisiz erişim, sızıntı ya da kayıp yaşandığında veri sorumlusunun yükümlülükleri devreye girer ve burada hız kritiktir. Pratikte beklenen akış şudur: ihlali fark etmek (bunun için önceden kurulu log/izleme şart), kapsamı belirlemek (hangi veri, kaç kişi, ne zaman), Kurul'a en kısa sürede bildirim yapmak ve etkilenen kişileri bilgilendirmek. Dikkat edilmesi gereken nokta, "ihlali fark edememe"nin de başlı başına bir eksiklik sayılmasıdır — OWASP Top 10:2025'teki A09 Security Logging and Monitoring Failures başlığının önemi tam burada netleşir: log tutmayan bir site, ihlali ne tespit edebilir ne de yükümlü olduğu bildirimi zamanında yapabilir.

Bu yüzden ihlal hazırlığı, panik anında değil proje aşamasında kurulur. Asgari hazırlık seti şunları içerir: erişim ve işlem loglarının tutulması, kritik olaylar için alarm/izleme, güncel bir veri envanteri (hangi formda hangi veri toplanıyor, nerede saklanıyor), yedeklerin hazır ve test edilmiş olması, ve bir olay müdahale akışının önceden tanımlanması (kim haberdar olacak, kim Kurul'a bildirecek). Bu hazırlık, aynı zamanda mevcut bir siteyi yenilerken de gözden geçirilmesi gereken bir kalemdir; eski, bakımsız ve loglama içermeyen bir altyapı, web sitesi yenileme kararının en güçlü gerekçelerinden biridir. Yenileme sırasında güvenlik ve uyumu sıfırdan doğru kurmak, sonradan yama yapmaktan hem daha ucuz hem de hukuken çok daha güvenlidir.

Özetle Türkiye bağlamında web güvenliği üç ayağı aynı anda gerektirir: teknik güvenlik (HTTPS, OWASP uyumlu yapılandırma, form/giriş koruması), yasal uyum (KVKK aydınlatma + ayrı açık rıza, çerez yönetimi, VERBİS, yurt dışı aktarım disiplini) ve süreklilik (güncelleme, yedekleme, izleme, ihlal hazırlığı). Bu üçünden biri eksikse, diğer ikisi tek başına sizi ne saldırılardan ne de yasal yaptırımlardan korur. Doğru yaklaşım, güvenliği projenin sonuna bırakılan bir kontrol kalemi değil, ilk günden mimarinin parçası yapan bir disiplindir.

Web Sitesi Güvenliği İçin Kontrol Listesi ve En Sık Yapılan Hatalar

Web sitesi güvenliği tek seferlik bir kurulum değil, düzenli tekrarlanan bir kontrol döngüsüdür. Aşağıdaki kontrol listesi, bir siteyi yayına alırken ve sonrasında periyodik olarak gözden geçirirken kullanabileceğiniz somut maddeleri içerir. Müşterilerimizde gördüğümüz en yaygın sıkıntı, güvenliğin "bir kere yapılıp unutulan" bir iş gibi ele alınması ve bu yüzden zamanla açık birikmesidir. Bir eklenti güncellenmeden geçen her ay, değişmeyen her varsayılan parola, alınmayan her yedek; tek tek küçük görünen ama biriktikçe ihlale dönüşen borçlardır. Liste, OWASP Top 10:2025 (8. baskı, 175.000'den fazla CVE analizine dayanır) başlıklarını, KVKK'nın teknik tedbir yükümlülüklerini ve Türkiye pratiğini birlikte kapsayacak şekilde önceliklendirilmiştir.

Kontrol listesini en verimli kullanmanın yolu, onu iki ayrı ana çevirmektir. Birincisi yayın öncesi (go-live) denetimi: site canlıya çıkmadan, ideal olarak staging ortamında, tüm maddelerin baştan sona işaretlendiği tek seferlik bir geçiş. İkincisi periyodik bakım denetimi: yayından sonra aylık veya üç aylık tekrarlanan, özellikle güncelleme, yedek ve log maddelerine odaklanan kısa bir kontrol. Müşterilerimizde gözlemlediğimiz en sağlıklı yapı, bu iki anı bir takvime bağlamaktır; çünkü "hatırlayınca yapılan" güvenlik, pratikte "hiç yapılmayan" güvenliktir.

Yayına Alma ve Periyodik Güvenlik Kontrol Listesi

Bu tabloyu hem yeni bir site yayınlamadan önce hem de mevcut sitenizde düzenli (örneğin aylık/üç aylık) denetim için kullanabilirsiniz. "Öncelik" sütunu hangi maddeyi ertelemeden ele almanız gerektiğini gösterir; "Kritik" olanlar tek başına ciddi açık demektir ve canlıya çıkmadan kapatılmalıdır.

Tabloyu kullanırken pratik bir önceliklendirme kuralı işe yarar: önce "Kritik" satırların tamamını kapatın (bunlar tek başına ihlal kapısı açan açıklardır), ardından "Yüksek", en son "Orta" olanlara geçin. Yayın gününde bir "Kritik" madde açık kalıyorsa, sitenin canlıya alınmasını ertelemek, sonradan bir ihlali temizlemekten her zaman daha ucuzdur. Bir başka somut ipucu: her maddeyi "kim sorumlu, ne sıklıkta, en son ne zaman yapıldı" üçlüsüyle kayıt altına alın; sorumlusu belirsiz bir güvenlik maddesi, pratikte sahipsiz kalır.

Bu maddeleri sıfırdan kurarken altyapı seçimleriyle (hosting, SSL, DNS) iç içe ilerlemeniz gerekir; domain, hosting ve SSL altyapısı rehberimizde bu temel katmanı, web sitesi nasıl yapılır rehberimizde ise yayın öncesi kontrol listesinin tamamını adım adım ele alıyoruz. Sitenizin hangi altyapı üzerinde çalıştığını ve eklenti yüzeyini hızlıca görmek için e-ticaret altyapı tespit aracımızı kullanabilirsiniz; çünkü güvenlik önceliklerinizi çoğu zaman kullandığınız platform (WordPress, Shopify, ikas, özel yazılım) belirler.

En Sık Yapılan Güvenlik Hataları ve Nasıl Önlenir?

Aşağıdaki hatalar, ihlallerin büyük çoğunluğunun arkasındaki birkaç tekrarlayan kök nedendir. Hiçbiri "gelişmiş hacker" senaryosu değildir; tamamı ihmalden kaynaklanır ve düzenli bir bakım disipliniyle önlenebilir. Bunları tek tek ele almadan önce şunu vurgulamak gerekir: saldırıların ezici çoğunluğu hedefli değil fırsatçıdır. Botlar internet genelinde bilinen açıkları tarar; sizin siteniz "ilginç" olduğu için değil, açık bir kapı bıraktığı için hedef olur. Bu yüzden temel hijyeni kapatmak, ileri seviye savunmadan önce gelir.

1. Güncelleme ihmali (en yaygın ihlal nedeni)

Müşterilerimizde gördüğümüz en sık kök neden budur: CMS çekirdeği, tema veya eklentinin aylarca güncellenmemesi. Bilinen açıkların (CVE) çoğu, yamanın yayınlanmış ama siteye uygulanmamış olması nedeniyle sömürülür. Yani saldırgan sıfırıncı gün (zero-day) bir açık bulmaz; çoktan kamuya açıklanmış, yaması yayınlanmış ama sizin sitenize işlenmemiş bir açığı kullanır. OWASP Top 10:2025'te A03 Software Supply Chain Failures başlığının ayrı bir kategori olarak eklenmesi, bu sorunun ölçeğini gösteriyor. Özellikle WordPress tarafında durum kritik: WordPress tüm web sitelerinin yaklaşık %41,9'unu çalıştırdığı için (W3Techs, Haziran 2026) saldırganların en çok hedef aldığı yüzeydir ve en büyük risk çekirdek değil, güncellenmemiş veya terk edilmiş üçüncü taraf eklentilerdir. WordPress ekosistemi 60.000'den fazla eklentiyle muazzam esneklik sunar; ama her eklenti aynı zamanda bakım gerektiren bir bağımlılık ve potansiyel bir giriş noktasıdır.

Nasıl önlenir:

• Güncelleme takvimi kurun: Çekirdek, tema ve eklentileri en az ayda bir gözden geçirin; kritik güvenlik yamalarını beklemeden uygulayın. "Kritik güvenlik" etiketli güncellemeler için bekleme süresini sıfıra indirin.
• Yüzeyi küçültün: Kullanmadığınız eklenti ve temaları pasifleştirmek yetmez, tamamen silin. Pasif bir eklenti bile sunucuda dosya olarak durduğu için saldırı yüzeyidir. Her ekstra bileşen yeni bir risktir.
• Güvenilir kaynak seçin: Aktif geliştirilen, düzenli güncellenen, geniş kullanıcı tabanı olan eklentileri tercih edin; uzun süredir güncellenmeyen (terk edilmiş) eklentileri kaldırın. Bir eklentinin "son güncelleme tarihi" ve aktif yükleme sayısı, sağlık göstergesidir.
• Önce staging'de test edin: Büyük güncellemeleri canlıya almadan önce test ortamında deneyin; bu, hem güvenlik açığını hem de güncelleme sonrası site çökmesini önler.
• Bağımlılık taraması ekleyin: Özel yazılımda (örn. Next.js/React tabanlı projeler) paket bağımlılıklarını bilinen açıklara karşı düzenli tarayan otomatik araçlar kullanın; tedarik zinciri riskini erken yakalarsınız.

WordPress mi yoksa daha az bakım yükü olan bir altyapı mı sizin için doğru sorusu, çoğu zaman güvenlik bütçenizi de belirler: yönetilen (managed) bir kurucuda altyapı bakımı sağlayıcıda olur, WordPress'te güncelleme sorumluluğu tamamen sizdedir, özel yazılımda ise yüzey daha dar ama bakımı ekibiniz/ajansınız üstlenir. Bu kararı CMS seçimi rehberimizde ve hazır site mi özel yazılım mı yazımızda ayrıntılı karşılaştırıyoruz.

2. Yedeksizlik (veya test edilmemiş yedek)

İkinci en pahalı hata, düzenli yedek almamak ya da yedek aldığını sanıp aslında geri yüklenemeyen bir yedeğe güvenmektir. Bir saldırı, sunucu arızası veya hatalı bir güncelleme sonrası geri dönüşün tek yolu çoğu zaman temiz bir yedektir; yedek yoksa site sıfırdan kurulur ve veri kalıcı kaybolur. Sağlıklı bir yedekleme şu dört özelliği taşımalıdır: otomatik (insan unutkanlığına bağlı değil), düzenli (sitenin değişim hızına uygun sıklıkta), sürümlü (birkaç gün/hafta geriye gidebilmeli; çünkü saldırı çoğu zaman fark edilmeden önce başlar) ve site dışı / off-site (yedek aynı sunucuda durmamalı, yoksa sunucu ele geçirildiğinde yedek de gider).

Sürümlü olmanın neden bu kadar önemli olduğunu bir örnekle netleştirelim: birçok saldırıda site bir anda çökmez; saldırgan haftalarca fark edilmeden zararlı kod enjekte eder. Eğer yalnızca "son yedek" tutuluyorsa, o yedek de büyük olasılıkla zaten zehirlenmiş durumdadır ve geri yükleme sizi temizlemez. Birkaç hafta geriye giden sürümlü yedek, "enfeksiyon öncesi" temiz bir noktaya dönmenizi sağlar. Aynı mantık, sitenizin kişisel veri tutması durumunda KVKK açısından da geçerlidir: veri kaybı, bir ihlal olarak değerlendirilebilir.

En kritik nokta ise geri yükleme testidir: yedeğin var olması yetmez, periyodik olarak gerçekten geri yüklenip yüklenmediği denenmelidir. Test edilmemiş bir yedek, ihtiyaç anında bozuk çıkarsa hiç olmamasından farksızdır. Pratik bir öneri: en azından üç ayda bir, yedeği bir test ortamına gerçekten geri yükleyin ve sitenin ayağa kalktığını gözünüzle doğrulayın. Yedekleme aynı zamanda KVKK m.12 kapsamındaki "veri güvenliği tedbirleri" yükümlülüğünün de parçasıdır.

3. Sadece istemci tarafı doğrulama yapmak

Sık görülen bir geliştirme hatası, form doğrulamasını yalnızca tarayıcıda (JavaScript ile) yapıp sunucu tarafında atlamaktır. Saldırgan tarayıcıyı tamamen bypass ederek doğrudan sunucuya istek gönderebileceği için, her doğrulama mutlaka sunucu tarafında tekrarlanmalıdır. Bunu somutlaştıralım: tarayıcıda "e-posta alanı zorunlu" ve "fiyat negatif olamaz" kontrolleri kullanıcı deneyimi için harikadır; ama saldırgan bu arayüzü hiç çalıştırmadan, bir araçla sunucuya doğrudan istek atarak boş veya negatif değer gönderebilir. Eğer sunucu bu değeri körü körüne kabul ederse, sipariş tutarını manipüle etmekten veritabanına zararlı içerik yazmaya kadar pek çok kapı açılır.

Aynı şekilde girdi temizleme (injection/XSS önleme), parametreli sorgular ve çıktı kaçışlama sunucu katmanında zorunludur. A05 Injection başlığının kapsadığı SQL injection ve XSS, doğrudan bu disiplinin eksikliğinden doğar. Doğru yaklaşım katmanlıdır: istemci tarafı doğrulama yalnızca kullanıcı deneyimi içindir (anında geri bildirim), gerçek güvenlik ise her zaman sunucuda kurulur. Pratik kural: "Sunucuya gelen hiçbir veriye güvenme, tarayıcı ne göndermiş olursa olsun yeniden doğrula."

4. Zayıf yönetici parolaları ve eksik 2FA

Yönetim girişleri kaba kuvvet (brute-force) saldırılarının birincil hedefidir. "admin" gibi tahmin edilebilir kullanıcı adları, zayıf parolalar ve 2FA'nın bulunmaması, en kolay sömürülen açıklardandır. Botlar, bilinen kullanıcı adı listeleri ve sızdırılmış parola veritabanlarıyla saniyeler içinde binlerce deneme yapar; insan müdahalesi olmadan, gece boyunca. Bu yüzden tek bir zayıf yönetici parolası, tüm sitenin tek kapısı olabilir.

Önlem nettir ve katmanlıdır:

• Güçlü ve benzersiz parolalar: Yönetici parolaları uzun ve özgün olmalı; başka serviste kullanılan bir parola asla yönetim panelinde kullanılmamalı (sızıntı zincirini kırar).
• Tüm yönetici hesaplarında 2FA: İki faktörlü kimlik doğrulama, parola çalınsa bile girişi engeller. Türkiye'de yaygın bir kalıp olarak SMS tabanlı doğrulama da kullanılabilir; ancak mümkünse uygulama tabanlı (TOTP) yöntemler daha güvenlidir.
• Giriş denemelerinde rate-limit: Belirli sayıda başarısız denemeden sonra hesabı veya IP'yi geçici kilitleyin; kaba kuvvetin temel mantığını kırarsınız.
• Erişimi daraltın: Mümkünse yönetim paneline erişimi IP/coğrafya bazında sınırlayın veya panel adresini varsayılandan değiştirin (otomatik tarayan botların gürültüsünü azaltır).

OWASP Top 10:2025'te bu kapsam A07 Authentication Failures altında ele alınır. Yönetici girişi, sitenin en değerli ve en çok saldırıya uğrayan noktasıdır; buradaki her ek katman, doğrudan en yüksek riski azaltır.

5. Hassas bilgileri ve hataları sızdırmak

Üretim ortamında hata ayıklama (debug) modunun açık bırakılması, hata sayfalarının kullanıcıya yığın izi (stack trace), dosya yolları, sürüm numaraları veya veritabanı detayları göstermesi sık rastlanan bir yapılandırma hatasıdır. Bu bilgiler saldırgana saldırı haritası verir: hangi framework'ün hangi sürümünün kullanıldığını, dosya yapısını, hatta veritabanı tablo adlarını gören bir saldırgan, hangi bilinen açığı deneyeceğini birkaç saniyede bilir. Bir başka yaygın sızıntı, API anahtarlarının, veritabanı parolalarının veya gizli token'ların doğrudan koda/açık dosyalara gömülmesidir; bunlar daima koddan ve depodan ayrı, ortam değişkenlerinde tutulmalıdır.

OWASP Top 10:2025'te A02 Security Misconfiguration başlığının 5. sıradan 2. sıraya yükselmesi ve A10 Mishandling of Exceptional Conditions'ın yeni başlık olarak eklenmesi, bu hataların ne kadar yaygın olduğunu gösteriyor. Doğru yaklaşım: üretimde debug kapalı olmalı; hata sayfaları kullanıcıya genel, bilgi sızdırmayan bir mesaj göstermeli (örneğin sade bir "Bir hata oluştu" sayfası); teknik detay yalnızca sunucu loglarına yazılmalı ve bu loglar yetkisiz erişime kapalı olmalıdır. Loglara da parola, kart bilgisi veya kişisel veri yazmamaya dikkat edin; aksi halde log dosyasının kendisi bir veri ihlali kaynağına dönüşür.

6. Güvenliği "yayın anına" sıkıştırmak

Son ve en bütünsel hata, güvenliği yalnızca yayın günü düşünülen bir adım sanmaktır. Oysa bakım sürekli bir süreçtir: güvenlik güncellemeleri, yedekleme, log izleme, kırık link ve sertifika kontrolü düzenli tekrarlanmazsa site hızla hem güvenlik hem SEO açısından değer kaybeder. Bunun çok somut bir örneği SSL sertifikasının süresinin sessizce dolmasıdır: kimse takip etmediği için bir gün ziyaretçiler "güvenli değil" uyarısıyla karşılaşır, hem güven hem sıralama zarar görür. Aynı sessiz erozyon, aylarca uygulanmayan güncellemelerde ve hiç bakılmayan loglarda da yaşanır.

OWASP Top 10:2025'te A06 Insecure Design başlığı tam da bunu vurgular: güvenlik sonradan eklenen bir katman değil, baştan tasarıma gömülmesi gereken bir ilkedir. Bu yüzden güvenlik kontrol listesini bir kez işaretleyip kapatmayın; takvime bağlayın, sorumlusunu belirleyin ve periyodik denetimi rutin hâline getirin. Bir site yenileme (redesign) sürecinde de bu döngü baştan kurulmalıdır; çünkü yenileme, eski açıkları temizlemek ve güvenliği yeni mimariye gömmek için en doğru fırsattır. Nasıl yapılacağını web sitesi yenileme rehberimizde anlatıyoruz.

Özet ve Sonraki Adım

Web sitesi güvenliği, birkaç temel disiplinin tekrarına dayanır: HTTPS'i zorunlu kıl, her şeyi güncel tut, sunucu tarafında doğrula, yönetici girişlerini 2FA ile koru, düzenli ve test edilmiş off-site yedek al, hataları sızdırma ve bunları bir kez değil sürekli yap. Bu altı disiplin, ihlallerin büyük çoğunluğunu oluşturan ihmal kaynaklı açıkların hemen hepsini kapatır; geriye kalan "gelişmiş" tehditler ise zaten ancak bu temel sağlamken anlam kazanır. Türkiye'de bu teknik tedbirler aynı zamanda KVKK m.12 kapsamında yasal bir yükümlülüktür; güvenlik açığı sadece teknik değil hukuki risktir ve kişisel veri işleyen her site bir veri sorumlusudur. Yukarıdaki kontrol listesini sitenizde madde madde uyguladığınızda, somut, ölçülebilir bir koruma seviyesine ulaşırsınız.

Sitenizin güvenlik, performans ve uyumluluk durumunu birlikte değerlendirmek isterseniz, ücretsiz site analizi üzerinden mevcut altyapınızı inceleyebilir; kurumsal bir güvenlik ve bakım yapısı kurmak için özel yazılım ve web sitesi hizmetimizle başından sonuna güvenli bir altyapı kurgulayabiliriz. Güvenlik kadar kritik olan erişilebilirlik tarafını da kapsamak için web erişilebilirliği rehberimize, sitenizin hızını ve Core Web Vitals durumunu ölçmek içinse site hızı ve Core Web Vitals rehberimize göz atmanızı öneririz; çünkü 2026'da güvenli, hızlı ve erişilebilir olmak, artık birbirinden ayrılamayan üç temel kalite katmanıdır.