Giriş
Bir web sitesi kurulduğunda çoğu kişi tasarıma, görsellere ve içerik girişine odaklanır. Asıl kritik kısım ise genelde görünmeyen taraftadır: alan adı ayarları, SSL, yönlendirmeler, email teslimatı, güvenlik başlıkları, form korumaları ve uygulama açıkları.
Benim bakışım net: Site açılıyor diye sağlıklı sayılmaz. Sağlıklı site; güvenli, hızlı, doğru yönlenen, maili çalışan, arama motorlarına temiz sinyal veren ve saldırıya davetiye çıkarmayan sitedir.
Bu rehberin amacı sadece bilgi vermek değil. Adım adım kontrol edebileceğin, eksiklerini bulabileceğin ve düzeltebileceğin pratik bir yapı sunmaktır.
Tanım: Bu rehber ne işe yarar?
Bu içerik, bir web sitesinin yayına alınmadan önce ve yayındayken teknik açıdan sağlam olup olmadığını kontrol etmek için hazırlanmış bir denetim rehberidir.
Buradaki mantık şudur: kontrol et → eksik bul → düzelt → tekrar test et.
Kimler için / Kimler için değil
Kimler için uygundur?
- Kendi sitesini kuran geliştiriciler
- Müşteri siteleri yöneten freelancer ve ajans ekipleri
- Web projesini sağlam temelle yayına almak isteyen işletmeler
- “Site çalışıyor ama içim rahat değil” diyenler
Kimler için uygun değildir?
- Sadece tasarımı yeterli görenler
- Teknik riskleri önemsemeyenler
- Kontrol ve bakım süreciyle hiç ilgilenmek istemeyenler
Sorun → Yaklaşım → Sonuç
1. Sorun
Birçok site şu mantıkla yayına çıkıyor: tasarım bitti, form çalışıyor, tamamdır. Sonra problemler geliyor. Mailler spam’e düşüyor, bazı sayfalar http açılıyor, yönlendirmeler dağınık oluyor, panel korunmuyor, formlar saldırıya açık kalıyor.
2. Yaklaşım
Doğru yaklaşım, siteyi tek parça görmek değil; katman katman incelemektir. Domain, DNS, SSL, yönlendirme, CDN, email, uygulama güvenliği, SEO ve performans ayrı ayrı kontrol edilmelidir.
3. Sonuç
Bu mantıkla ilerlersen daha güvenli, daha hızlı, daha sürdürülebilir ve bakım maliyeti daha düşük bir siteye sahip olursun.
Alan Adı & DNS
Her şey domain ve DNS ile başlar. Buradaki hata, sitenin bazı kullanıcılar için açılmamasına, mail tarafının bozulmasına veya yanlış sunucuya gitmesine neden olabilir.
- Alan adı doğru sağlayıcıdan alındı mı?
- A kaydı doğru IP’ye yönleniyor mu?
- www ve non-www için tek bir ana versiyon belirlendi mi?
- TTL değerleri gereksiz yüksek bırakılmadı mı?
- Gereksiz eski DNS kayıtları temizlendi mi?
Nasıl yapılır?
Tek bir ana domain yapısı seç. Örneğin siten https://www.siteadi.com üzerinden çalışacaksa, diğer tüm versiyonları buna yönlendir. Hem http, hem https, hem www, hem de non-www ayrı ayrı erişilebilir kalmamalı.
Örnek problem:
siteadi.com açılıyor ama www.siteadi.com açılmıyorsa ya da başka bir içeriğe gidiyorsa DNS veya yönlendirme tarafında problem var demektir.
SSL & Temel Güvenlik
HTTPS artık opsiyon değil. Zorunlu. Ama sertifika kurmak tek başına yeterli değil; düzgün yönlendirme ve güvenlik başlıkları da gerekir.
- SSL sertifikası aktif mi?
- Tüm trafik HTTP’den HTTPS’e yönleniyor mu?
- Mixed content hatası var mı?
- HSTS kullanılıyor mu?
- Güvenlik başlıkları en az temel seviyede tanımlı mı?
Nasıl yapılır?
SSL kurulduktan sonra sadece ana sayfayı değil, alt sayfaları, görselleri, JS ve CSS dosyalarını da kontrol et. Çünkü sayfa HTTPS açılıp içindeki bir görsel HTTP’den geliyorsa tarayıcı bunu sorun olarak görür.
Örnek:
Sayfa https:// ile açılıyor ama konsolda mixed content uyarısı varsa, bazı kaynaklar hâlâ güvensiz bağlantıdan yükleniyordur.
Cloudflare & CDN
Cloudflare gibi servisler sadece hız için değil, aynı zamanda koruma ve yönetim kolaylığı için de önemlidir.
- DNS yönetimi doğru yapılıyor mu?
- Proxy gereken kayıtlar için açık mı?
- Cache mantığı rastgele değil bilinçli mi kurulmuş?
- DDoS ve temel bot korumaları kullanılıyor mu?
- Always Use HTTPS ve benzeri temel ayarlar açık mı?
Nasıl yapılır?
Statik dosyaları cache’leyip admin, panel, ödeme ve kullanıcıya özel sayfaları bilinçsizce cache’leme. Aksi halde kullanıcı yanlış veri görebilir.
Örnek hata:
Form gönderildiği halde eski içerik görünüyorsa veya panelde değişiklik yapıp sonucu göremiyorsan agresif cache kuralı sorun çıkarıyor olabilir.
Email & MX Ayarları
Email altyapısı çoğu projede son anda düşünülür. Sonra da “mail gidiyor ama bazen spam’e düşüyor” cümlesi başlar. Bu taraf ciddidir.
- MX kayıtları doğru mu?
- SPF tanımlı mı?
- DKIM aktif mi?
- DMARC politikası yazıldı mı?
- Gönderici domain ile gönderim yapan sunucu birbiriyle tutarlı mı?
Nasıl yapılır?
Form mailleri, sistem mailleri ve normal kurumsal mail akışı aynı mantıkla düşünülmemeli. Web sitesi üzerinden mail gönderiyorsan SPF ve DKIM tarafı düzgün değilse teslimat kalitesi düşer.
Örnek:
SPF kaydı yoksa ya da yanlışsa, formdan gönderdiğin bildirim mailleri karşı tarafta spam klasörüne düşebilir veya tamamen reddedilebilir.
Uygulama Güvenliği
İşin en kritik tarafı burası. Çünkü tasarım bozulursa utanırsın, güvenlik açığı olursa zarar görürsün.
- Input validation yapılıyor mu?
- Output escaping uygulanıyor mu?
- CSRF token kullanılıyor mu?
- Admin paneline erişim sınırlandırıldı mı?
- Hatalar son kullanıcıya açık şekilde gösterilmiyor mu?
- Dosya yükleme alanları kontrol ediliyor mu?
- Oturum ve cookie ayarları güvenli mi?
Nasıl yapılır?
Kullanıcıdan gelen her veriyi potansiyel risk kabul et. “Bu alana zaten normal insan isim yazacak” mantığı hatalıdır. Saldırgan isim alanına isim yazmaz; script, payload ve bozucu veri gönderir.
XSS gerçekten önemli mi?
Evet, önemli. Hem de ciddi önemli. Çünkü çok yaygın, çok hafife alınan ve bazen tek bir form alanından başlayabilen bir açıktır.
XSS yani Cross-Site Scripting, saldırganın siteye zararlı JavaScript enjekte etmesi ve bunun başka kullanıcıların tarayıcısında çalışmasıdır.
Basit anlatımla: Senin sistemin, kullanıcının girdiği veriyi olduğu gibi ekrana basarsa saldırgan bu alanı kötüye kullanabilir.
Örnek payload’lar:
<script>alert(document.cookie)</script>
<img src=x onerror=alert('XSS')>
Bu örnekler basit görünüyor ama mantık şu: Eğer sistem bunları filtrelemeden ya da güvenli biçimde encode etmeden sayfada çalıştırırsa, saldırgan kullanıcı oturumlarını hedefleyebilir, form alanlarını manipüle edebilir, sahte arayüz gösterebilir veya admin kullanıcıyı kandırabilir.
Gerçek riskler:
- Çerez ve oturum bilgisi ele geçirme girişimleri
- Kullanıcıyı sahte buton ve sahte form ile kandırma
- Admin panelinde işlem yaptırma
- Sayfaya zararlı içerik enjekte etme
- Marka güvenini bozma
Kritik nokta: XSS sadece yorum alanında olmaz. Arama kutusu, iletişim formu, destek talebi, profil adı, admin notu, hatta URL parametresi bile kaynak olabilir.
XSS ve benzeri açıklar nasıl kontrol edilir?
1. Input alanlarını test et
Form, arama kutusu, yorum alanı, giriş ekranı, admin paneli gibi kullanıcı veri girebilen alanlara kontrollü test payload’ları gönder.
Örnek test verileri:
<script>alert(document.cookie)</script>
<img src=x onerror=alert('XSS')>
<svg onload=alert('XSS')>
"><script>alert('XSS')</script>
Eğer bu içerik kaydedilip sonra sayfada çalışıyorsa açık vardır. Eğer düz metin olarak görünüyorsa veya filtreleniyorsa doğru yoldasındır.
2. Kaynak kod ve çıktıyı kontrol et
Tarayıcıda sayfa kaynağını ve geliştirici araçlarını aç. Kullanıcıdan gelen veri HTML içine nasıl basılmış bak. Doğrudan innerHTML ile basılıyorsa risk büyür. Güvenli text output tercih edilmelidir.
3. Output escaping var mı bak
PHP tarafında ekrana basılan kullanıcı verileri için uygun kaçış işlemleri uygulanmalı. Örneğin HTML çıktısında özel karakterler encode edilmezse XSS ihtimali doğar.
Örnek mantık:
Kullanıcı adını doğrudan basmak yerine güvenli şekilde encode ederek basman gerekir. Yoksa isim alanı script alanına döner.
4. CSP ve güvenlik başlıklarını değerlendir
Content-Security-Policy tek başına sihir değildir ama zararı azaltır. Inline script kullanımını kısıtlamak ve güvenilir kaynakları tanımlamak faydalıdır.
5. Admin tarafını ayrıca test et
Bazı açıklar public tarafta değil, panelde patlar. Kullanıcı formdan zararlı veri gönderir, admin o kaydı panelde açınca script çalışır. Buna özellikle dikkat et.
6. Sadece blacklist mantığına güvenme
<script> kelimesini yasaklamak tek başına çözüm değildir. Saldırılar farklı event handler’larla, attribute’larla veya encode edilmiş yöntemlerle gelebilir. Sağlam yöntem: doğru validation + doğru output escaping + gerektiğinde CSP.
7. Dosya yükleme alanlarını test et
Yüklenen dosyanın sadece uzantısına değil MIME tipine, içerik yapısına ve sunucuda nasıl servis edildiğine bak. SVG gibi dosyalar bile bazı senaryolarda script riski taşıyabilir.
8. Log ve hata ekranlarını incele
Hata mesajları kullanıcıya ham biçimde dönüyorsa hem bilgi sızar hem de farklı açıklar için ipucu verir. Production ortamında detaylı hata gösterme.
Pratik “şöyle yap” özeti
- Kullanıcıdan gelen veriyi asla güvenli kabul etme
- Sunucu tarafında validation yap
- Çıktıda encode/escape uygula
- Admin panelini IP, giriş kontrolü ve 2FA ile koru
- CSRF token kullan
- Dosya yüklemeyi sıkı kontrol et
- HTTP güvenlik başlıklarını yapılandır
- Test payload’larıyla kontrollü deneme yap
Sık Sorulan Sorular
Cloudflare kullanmak zorunlu mu?
Hayır. Ama hız, temel koruma ve DNS yönetimi açısından ciddi kolaylık sağlar.
SSL ücretsiz olabilir mi?
Evet. Let’s Encrypt ile çoğu senaryoda ücretsiz SSL kurulabilir.
MX ayarları SEO’yu etkiler mi?
Doğrudan değil. Ama mail teslimatı ve marka güveni tarafını etkiler. Bu da dolaylı olarak iş sonuçlarını etkiler.
XSS gerçekten küçük sitelerde de önemli mi?
Evet. Küçük site olduğun için saldırmazlar sanmak hatadır. Otomatik taramalar küçük-büyük ayırmaz.
Antivirüs veya WAF varsa XSS çözülür mü?
Hayır. Yardım eder ama kötü kod yazımını telafi etmez. Esas çözüm uygulama mantığını güvenli kurmaktır.
Yanlış bilinenler
- “Site açıldıysa sorun yoktur.” → Yanlış
- “SSL varsa site güvenlidir.” → Eksik ve yanıltıcı
- “XSS sadece büyük sitelerin sorunudur.” → Yanlış
- “Formda required alan var, güvenlik tamam.” → Alakasız
- “Sadece script tag engellenirse yeter.” → Yetersiz
Sonuç
Web sitesi kurmak sadece sayfa hazırlamak değildir. Sistem kurmaktır. Domain, SSL, yönlendirme, email, cache, güvenlik ve uygulama mantığı birlikte düzgün çalışmıyorsa o site profesyonel görünse bile sağlam değildir.
Özellikle XSS gibi açıklar küçümsenecek konu değildir. Çünkü çoğu zaman “küçük bir input alanı” diye geçiştirilen yerden başlar. Doğru kontrol yaparsan riskleri ciddi ölçüde azaltırsın. Yapmazsan gün gelir biri senin yerine test eder.
