Güncellendi: 1 Ekim 2026
Bir web sitesinin tarayıcıda düzgün açılması, güvenli olduğu anlamına gelmez. Yayına çıkış anı; yönetici hesapları, sunucu ayarları, formlar, yedekleme, üçüncü taraf eklentiler ve hata kayıtlarının aynı anda gerçek kullanıcı trafiğine açıldığı noktadır. Bu nedenle güvenlik kontrolü, lansman sonrasına bırakılacak ayrı bir iş değil yayın öncesi kontrol listesinin parçası olmalıdır.
1. HTTPS gerçekten her yerde çalışıyor mu?
SSL sertifikasının kurulmuş olması tek başına yeterli değildir. Ana sayfa, alt sayfalar, görseller, JavaScript ve CSS dosyaları HTTPS üzerinden yüklenmelidir. HTTP adreslerinden HTTPS’e tek ve kalıcı yönlendirme yapılmalı; sayfa içinde HTTP kaynakları kalıp “mixed content” oluşturmamalıdır.
- HTTP → HTTPS yönlendirmesini kontrol edin.
- www ve www olmayan alan adı sürümlerinden hangisinin kullanılacağını belirleyin.
- Canonical adreslerin seçilen HTTPS sürümünü göstermesini doğrulayın.
- Form ve giriş sayfalarında da HTTPS kullanıldığından emin olun.
2. Yönetici hesaplarını yayın öncesi temizleyin
Test aşamasında açılmış geçici yönetici hesapları, ortak kullanılan parolalar veya artık projede çalışmayan kişilere ait hesaplar canlıya taşınmamalıdır. Her kullanıcıya işi için gereken en düşük yetki verilmelidir.
- Gereksiz yönetici hesaplarını kaldırın.
- Varsayılan veya kolay tahmin edilen kullanıcı adlarını kullanmayın.
- Uzun ve benzersiz parolalar kullanın.
- Mümkün olan yönetim sistemlerinde iki faktörlü doğrulamayı etkinleştirin.
- Ajans veya geliştirici erişimlerinin kime ait olduğunu kayıt altına alın.
3. Üretimde hata mesajlarını ziyaretçiye göstermeyin
Geliştirme ortamında ayrıntılı hata mesajları faydalıdır; canlı sitede ise dosya yolları, veritabanı ayrıntıları veya kullanılan yazılım bileşenleri hakkında gereksiz bilgi sızdırabilir. Hatalar ekranda gösterilmek yerine güvenli log dosyalarına yazılmalıdır.
WordPress kullanıyorsanız WP_DEBUG_DISPLAY gibi geliştirme ayarlarının canlı ortamda açık kalmadığını kontrol edin. PHP tarafında da display_errors üretimde ziyaretçiye açık olmamalıdır.
4. Yazılım, tema ve eklenti envanterini çıkarın
Kurulu fakat kullanılmayan eklenti ve temalar da saldırı yüzeyinin parçasıdır. “Pasif olduğu için sorun olmaz” yaklaşımı doğru değildir; sunucuda bulunan eski dosyalar ayrıca takip edilmelidir.
- Kullanılmayan tema ve eklentileri kaldırın.
- CMS, eklenti ve tema sürümlerinin güncelliğini kontrol edin.
- Kaynağı belirsiz veya lisansı güven vermeyen paketleri kullanmayın.
- Güncelleme öncesinde geri dönüş planı oluşturun.
5. Formlar ve dosya yüklemeleri özel olarak test edilmeli
İletişim formu, üyelik, dosya yükleme veya teklif formu gibi kullanıcıdan veri alan bölümler yalnız işlev açısından değil kötüye kullanım açısından da test edilmelidir. Sunucu tarafında doğrulama yapılmalı; dosya yükleme varsa izin verilen uzantı, MIME türü ve boyut sınırı tanımlanmalıdır.
Spam koruması kullanıyorsanız gerçek kullanıcıyı gereksiz yere engellemediğini de kontrol edin. Güvenlik ile kullanılabilirlik birlikte değerlendirilmelidir.
6. Dosya ve dizin izinlerini gözden geçirin
Web sunucusunun yazması gerekmeyen alanlara gereksiz yazma yetkisi verilmemelidir. Yapılandırma dosyaları ve yedekler doğrudan web üzerinden erişilebilir yerde tutulmamalıdır. Eski .zip, .sql, .bak ve benzeri yedek dosyaları özellikle kontrol edin.
7. Yedek almanın yanında geri yüklemeyi de test edin
“Yedek var” demek ancak geri yükleme yapılabildiğinde anlamlıdır. Yayına çıkmadan önce dosya ve veritabanının ayrı ayrı yedeklendiğini, yedeğin farklı bir konumda tutulduğunu ve gerektiğinde geri dönebildiğinizi doğrulayın.
- Veritabanı yedeği
- Yüklenen medya ve dosyalar
- Tema/uygulama kodu
- Yapılandırma dosyaları
- DNS ve kritik servis bilgileri
8. Güvenlik başlıklarını kontrol edin
Uygulamanın yapısına uygun güvenlik başlıkları tarayıcı tarafındaki bazı riskleri azaltmaya yardımcı olabilir. HSTS, Content-Security-Policy, X-Content-Type-Options ve Referrer-Policy gibi başlıklar körlemesine eklenmemeli; kullanılan servislerle birlikte test edilmelidir. Özellikle ödeme, reklam, analitik veya harici medya servisleri varsa çok katı bir politika sitenin işlevini bozabilir.
9. Yönetim paneli ve giriş noktalarını izleyin
Giriş denemeleri, başarısız oturumlar ve olağandışı trafik için temel kayıt mekanizması oluşturun. Yönetim paneline erişimi yalnız URL gizleyerek güvenli kabul etmeyin. Asıl koruma; güçlü kimlik doğrulama, güncel yazılım, doğru yetki ve gerektiğinde oran sınırlamasıdır.
10. Lansman günü için kısa güvenlik kontrolü
- HTTPS ve yönlendirmeleri doğrulayın.
- Geçici hesapları kaldırın.
- Debug ve ekran hata gösterimini kapatın.
- Güncellemeleri ve gereksiz eklentileri kontrol edin.
- Formları ve dosya yüklemelerini test edin.
- Yedek alın ve geri dönüş noktasını doğrulayın.
- Web kökünde yedek, SQL veya geliştirme dosyası kalmadığını kontrol edin.
- Yönetici hesaplarında güçlü kimlik doğrulama kullanın.
- Hata ve güvenlik kayıtlarının tutulduğunu doğrulayın.
- Yayın sonrası ilk 24–48 saat logları ve olağandışı trafiği takip edin.
Bu kontrol güvenlik testinin tamamı değildir; ancak yeni bir web sitesinin en sık gözden kaçan temel risklerini yayın öncesinde azaltır. Daha geniş lansman kontrolü için yayın öncesi 25 maddelik kontrol listesini de kullanabilirsiniz.