Web Güvenliği 2025: Kontrol Listesi Rehberi

Web Güvenliği 2025 Kontrol Listesi Rehberi​

Web güvenliği tek seferlik kurulum değil, düzenli bakım ve ölçüm disiplinidir. Kimlik doğrulama, yetki, yama, TLS, güvenlik başlıkları, WAF, loglama, yedek ve olay müdahalesi birlikte çalışmadığında küçük açıklar ciddi kesintiye dönüşebilir.
Bu kontrol listesi, küçük ve orta ölçekli web siteleri için uygulanabilir bir güvenlik sırası sunar. Amaç panik üretmek değil; en yüksek riski taşıyan başlıkları düzenli kontrol edilecek hale getirmektir.

---

Neden Önemli?​

Web siteleri artık yalnızca vitrin değildir; üyelik, ödeme, iletişim formu, içerik yönetimi ve analitik gibi birçok veri akışını taşır. Zayıf parola, eski eklenti, yanlış dosya izni veya eksik yedek doğrudan itibar ve gelir kaybına neden olabilir.
Güvenlik listesi karmaşık olmak zorunda değildir. Önce kimlerin eriştiği, hangi yazılımların çalıştığı, hangi verilerin tutulduğu ve sorun olduğunda nasıl geri dönüleceği bilinmelidir. Bu dört soru netleşmeden gelişmiş araçlar tek başına yeterli olmaz.

Kimlik ve Yetki Kontrolü​

• 2FA: Yönetici, editör, geliştirici ve hosting paneli hesaplarında iki aşamalı doğrulama etkin olmalıdır.
• En az ayrıcalık: Her kullanıcı yalnızca işini yapmak için gereken role sahip olmalıdır.
• Hesap temizliği: Ayrılan çalışan, eski ajans ve kullanılmayan API anahtarları kapatılmalıdır.
• Parola politikası: Tekrar kullanılan veya paylaşılan parolalar yasaklanmalı; parola yöneticisi kullanılmalıdır.
• Oturum güvenliği: Admin oturum süreleri, cihazlar ve şüpheli girişler düzenli kontrol edilmelidir.

Yama ve Bağımlılık Bakımı​

Eski CMS, tema, eklenti ve kütüphaneler en sık istismar edilen riskler arasındadır. Güncelleme yapmadan önce yedek alınmalı, mümkünse staging ortamında test edilmeli ve canlıya düşük trafikli saatlerde çıkılmalıdır.
Bağımlılık bakımı yalnızca sürüm yükseltmek değildir. Kullanılmayan eklentileri kaldırmak, terk edilmiş paketleri değiştirmek, admin panelindeki deneme dosyalarını silmek ve hata loglarını incelemek de bakımın parçasıdır.

TLS ve Güvenlik Başlıkları​

HTTPS tüm sayfalarda zorunlu olmalı, HTTP'den HTTPS'e tek adım yönlendirme yapılmalı ve karışık içerik bırakılmamalıdır. HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy ve uygun CSP politikası riskleri azaltır.
CSP özellikle dikkatli uygulanmalıdır. Önce report-only modunda ihlal raporları izlenebilir, sonra politika daraltılır. Çok sert politika test edilmeden canlıya alınırsa ödeme, medya veya yönetim ekranları bozulabilir.

WAF, Rate Limit ve Bot Koruması​

• Login, kayıt, arama, yorum ve iletişim formu gibi uçlarda rate limit uygulanmalıdır.
• WAF hazır kural setleriyle başlatılmalı; yanlış pozitifler loglardan izlenmelidir.
• XML-RPC, eski upload uçları veya kullanılmayan API yolları gerekiyorsa sınırlandırılmalıdır.
• Admin paneli erişimi ek doğrulama, IP kısıtı veya güvenli giriş politikasıyla korunmalıdır.
• Bot trafiği, 404 patlaması, başarısız login ve 429 sayısı düzenli raporlanmalıdır.

Yedek ve Olay Müdahalesi​

Yedek almak yeterli değildir; geri yükleme testi yapılmayan yedek güvence sayılmaz. Dosya ve veritabanı yedeği ayrı tutulmalı, en az bir kopya farklı konumda saklanmalı ve geri dönüş süresi gerçekçi ölçülmelidir.
Olay müdahale planı kısa ve uygulanabilir olmalıdır: kim haberdar edilecek, site nasıl bakım moduna alınacak, hangi yedek kullanılacak, loglar nerede duruyor, kullanıcıya ne zaman bilgi verilecek ve güvenlik açığı nasıl kapatılacak yazılı olmalıdır.

Log ve KPI Takibi​

• Giriş denemesi: Başarısız admin login sayısı ve kaynak IP kırılımı.
• HTTP anomalisi: 403, 404, 429 ve 5xx artışları.
• Dosya değişimi: Beklenmeyen PHP, JS veya tema dosyası değişiklikleri.
• Performans sinyali: Ani TTFB veya hata oranı artışı.
• Yedek durumu: Son başarılı yedek ve son başarılı geri yükleme testi tarihi.

Mikro Vaka​

Bir forum sitesinde eski bir eklenti güncellenmeden bırakılmıştı. Önce staging ortamında sürüm testi yapıldı, ardından canlı güncelleme düşük trafikte uygulandı. Aynı gün güvenlik başlıkları ve yedek geri yükleme testi de kontrol edildi. Sorun çıkmadı; ekip sonraki güncelleme ritmini takvime bağladı.
Bu örnek, güvenliğin tek büyük proje yerine küçük ama düzenli kontrollerle sürdürülebileceğini gösterir.

Basit Formül​

SSS​

• İlk güvenlik adımı ne olmalı? Yönetici hesaplarında 2FA, rol temizliği ve tam yedek kontrolüyle başlanmalıdır.
• Güncellemeler hemen yapılmalı mı? Kritik güvenlik yamaları geciktirilmemeli; yine de yedek ve mümkünse staging testi yapılmalıdır.
• CSP şart mı? Her site için aynı sertlikte şart değildir; ancak script kaynaklarını kontrol etmek için güçlü bir araçtır.
• WAF tek başına yeterli mi? Hayır. WAF yardımcı katmandır; yama, yetki, log ve yedek disiplininin yerine geçmez.
• Yedek ne sıklıkla test edilmeli? Kritik sitelerde aylık, daha küçük sitelerde en az çeyreklik geri yükleme testi yapılmalıdır.
• Hangi metrikler izlenmeli? Başarısız giriş, 403/429/5xx artışı, dosya değişimi, son yedek ve güvenlik başlığı durumu izlenmelidir.

Aylık Güvenlik Ritmi​

Güvenlik işi takvime bağlanmadığında genellikle sadece sorun çıkınca hatırlanır. Aylık ritimde önce yedek ve geri yükleme durumu kontrol edilir, ardından CMS/eklenti/tema güncellemeleri incelenir, kullanıcı rolleri gözden geçirilir, güvenlik başlıkları test edilir ve log anomalileri raporlanır.
Bu toplantı kısa tutulabilir; önemli olan her ay aynı soruların sorulmasıdır. Son yedek ne zaman alındı, son geri yükleme ne zaman denendi, kaç başarısız admin girişi oldu, hangi eklenti güncelleme bekliyor, hangi güvenlik başlığı eksik veya değişmiş görünüyor?

Güvenlik Başlığı Yayın Planı​

Güvenlik başlıkları canlıya alınırken ölçülü ilerlemek gerekir. HSTS, Referrer-Policy ve X-Content-Type-Options çoğu sitede daha doğrudan uygulanabilir; CSP ise siteye özel kaynakları etkilediği için önce raporlama modunda denenmelidir. Ödeme, medya, reklam ve yönetim paneli scriptleri test edilmeden sert politika canlıya alınmamalıdır.

• Önce mevcut başlıklar ölçülür ve raporlanır.
• Düşük riskli başlıklar canlıya alınır.
• CSP report-only ile izlenir.
• Bozulan kaynaklar düzeltilir veya izin listesi daraltılır.
• Son politika sürümü ve tarih dokümana yazılır.

Olay Sonrası Öğrenme​

Güvenlik olayı yaşandıktan sonra yalnızca açığı kapatmak yeterli değildir. Olayın nasıl fark edildiği, hangi logların işe yaradığı, hangi uyarıların eksik kaldığı, yedeğin ne kadar hızlı döndüğü ve kullanıcı iletişiminin nasıl yapıldığı değerlendirilmelidir.
Bu değerlendirme suçlama toplantısı değil, sistem iyileştirme çalışmasıdır. Sonuçta yeni alarm, daha kısa güncelleme SLA'i, daha sık yedek testi veya daha dar yetki modeli çıkabilir. Böylece aynı olay tekrarlandığında ekip daha hızlı ve daha sakin hareket eder.

İç Bağlantılar​

• Web güvenliği hız ve güvenlik rehberi
• Kapsamlı web güvenliği rehberi
• Web güvenliği hataları ve çözümleri
• Teknik SEO ve performans kontrolü

Dış Kaynak​

• OWASP Top 10
• OWASP HTTP Security Response Headers Cheat Sheet
• MDN: Content-Security-Policy header
• MDN HTTP Observatory

Özetle​

Web güvenliği düzenli kontrol listesiyle yönetilir: kimlik, yama, TLS, güvenlik başlıkları, WAF, log ve yedek birlikte çalışmalıdır. En kritik adım, güvenlik kararlarını ölçülebilir ve tekrar edilebilir hale getirmektir.

Güncelleme: 2026-06-16

---