Web sitesi yayına alma kontrol listesi: canlıya geçmeden önce yapılacak sekiz güvenlik kontrolü

1. Yayın öncesi kontrol listesine genel bakış

Sunduğunuz her herkese açık adı, genellikle çıplak alan adını ve www’yu, hem http:// hem https:// üzerinden kontrol edin. DNS değişiminden önce yeni sunucuyu gerçek adla curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ komutuyla sınayabilirsiniz; örnekteki IP yerine yeni sunucunun IP adresini yazın.

Sekiz satır, ücretsiz Yayına Hazırlık Snapshot’ındaki sekiz pasif kontrolü izler; Snapshot hesap gerektirmeden tek bir herkese açık origin’e bakar. Aşağıdaki elle yapılan adımlar tek origin üzerindeki tek geçişten daha ileri gider: tüm ana makine adlarını, her iki şemayı, hata sayfalarını, DKIM’i ve kayıt şirketi ayarlarınızı kapsar.

2. DNS çözümlemesi: her ad yeni sunucuyu göstermeli

Neden önemli? Kısmi taşıma kolay gözden kaçar: çıplak alan adı yeni sunucudadır, ama www hâlâ eski platforma CNAME’dir. Artık kayıtlar güvenlik sorunudur da. OWASP alt alan adı ele geçirme rehberi, silinmiş bir bulut kaynağını gösteren CNAME’in alt alan adının başkası tarafından sahiplenilmesine nasıl yol açabileceğini; sahipsiz kalmış bir MX kaydının saldırganın o ad için posta almasına ve e-posta tabanlı doğrulamayla sertifika bile edinmesine nasıl izin verebileceğini açıklar.

Nasıl kontrol edilir?

dig +short A example.com
dig +short AAAA example.com
dig +short CNAME www.example.com
dig +short NS example.com

Ağınız önbelleğe alınmış bir yanıt tutuyor olabilir; sorguları herkese açık bir çözümleyiciyle (dig @1.1.1.1 …) tekrarlayın, ardından DNS sağlayıcınızdan tam bölge dışa aktarımını inceleyin.

İyi sonuç nasıl görünür? Her herkese açık ad beklediğiniz sunucuya çözülür, AAAA kayıtları yalnızca sunucu siteyi gerçekten IPv6 üzerinden sunuyorsa vardır, en az iki ad sunucusu yanıt verir (RFC 1034’ün koyduğu asgari değer) ve her kaydın bilinen bir amacı ve sorumlusu vardır.

Olağan çözüm. Eski kayıtları yeniden yönlendirin veya silin. Bir hizmeti kapatırken OWASP’ın önerdiği sırayı izleyin: DNS kaydını güncelleyin veya kaldırın, en az bir TTL bekleyin, bulut kaynağını ancak sonra silin. Geçişten önce TTL’i, eski ve daha uzun TTL geçiş anında dolmuş olacak şekilde yeterince erken düşürün; taşıma oturunca yeniden yükseltin.

3. SPF, DMARC ve CAA: alan adınız adına konuşan kayıtlar

Neden önemli? Herkes alan adınızı From satırına yazabilir. SPF, alan adı adına posta gönderebilecek sunucuları listeler, DKIM iletileri imzalar, DMARC ise ne SPF ne de DKIM görünen From alan adıyla hizalı biçimde geçmediğinde alıcıların ne yapacağını söyler. Gmail, Yahoo ve Outlook.com toplu gönderenlerden üçünü de ister. CAA, adlarınız için sertifika verebilecek sertifika otoritelerini belirtir; herkese açık CA’lar vermeden önce onu kontrol etmek zorundadır.

Nasıl kontrol edilir? From adreslerinizde kullanılan alan adını sorgulayın; bu genellikle www değil, kayıtlı alan adıdır:

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CAA example.com

İyi sonuç nasıl görünür?

• SPF: tam olarak bir v=spf1 kaydı, RFC 7208’in DNS sorgulayan en fazla 10 terim sınırı içinde (iç içe include’lar sayılır), ~all veya -all ile biten, asla +all olmayan.
• DMARC: v=DMARC1; p=none; rua=mailto:dmarc@example.com gibi bir kayıt; böylece politikayı sıkılaştırmadan önce raporlar gelir. Güncel standart RFC 9989 (Mayıs 2026), kullanıcıları posta listelerine yazabilecek alan adlarının p=reject yayımlamamasını söyler; yine de isteyenler önce en az bir ay p=none, ardından aynı süre quarantine ile çalışıp raporları karşılaştırmalıdır.
• DKIM: sizin adınıza gönderen her hizmet alan adınızla imzalar. Açık anahtarlar selector._domainkey.example.com adresindedir; onları sorgulamak için her selector’ı bilmeniz gerekir. Selector, hizmetin gönderdiği bir iletideki DKIM-Signature başlığının s= etiketinde görünür.
• CAA: kullandığınız her CA için, CDN’inizin kullandığı dahil, 0 issue "letsencrypt.org" gibi bir kayıt. CAA kaydının olmamasına izin verilir ve CAA, yetkili bir CA’nın hatalı sertifika vermesini engellemez.

Olağan çözüm. Yinelenen SPF kayıtlarını birleştirin, kullanımdan kalkmış hizmetlerin include’larını çıkarın ve DMARC’a raporlarla birlikte p=none ile başlayın. Sert başarısızlık otomatik olarak daha güvenli değildir: RFC 9989, -all kullanıldığında hizalı bir DKIM imzası geçecek olsa bile DMARC çalışmadan SPF sonucuna göre postanın reddedilebileceği ve bu retlerin DMARC raporlarında hiç görünmediği konusunda uyarır. Bir alt alan adında DMARC kaydı bulamayan alıcılar DNS ağacında üst alan adının politikasına çıkar; bir CA da sertifika verdiği adın kendisindeki veya üstündeki en yakın CAA kaydını kullanır, Let’s Encrypt’in CAA sayfası bunu açıklar. Dolayısıyla www üzerinde _dmarc veya CAA kaydının olmaması tek başına bir açık değildir. SPF ve DMARC kontrol rehberi bu kayıtların okunmasını ve düzeltilmesini anlatır; ücretsiz SPF ve DMARC kontrolü girdiğiniz ana makine adının SPF, DMARC, MTA-STS ve CAA kayıtlarını sorgular.

4. TLS sertifikası: geçerli, eşleşen ve biri tarafından yenilenen

Neden önemli? Süresi dolmuş veya eşleşmeyen sertifika ziyaretçileri tarayıcı uyarısında durdurur; HSTS kullanan bir sunucuda uyarıyı geçemezler. Yenilemeler de sıklaşıyor: CA/Browser Forum Ballot SC081v3 uyarınca, 15 Mart 2026’dan itibaren verilen herkese açık güvenilir sertifikalar en fazla 200 gün geçerlidir; bu süre Mart 2027’den itibaren 100 güne, Mart 2029’dan itibaren 47 güne düşer. Let’s Encrypt 4 Haziran 2025’te süre bitiş e-postaları göndermeyi bıraktı.

Nasıl kontrol edilir? Her ana makine adı için:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -enddate -ext subjectAltName

s_client’ı tek başına da çalıştırın: çıktıda Verify return code: 0 (ok) bulunmalı ve anlaşılan protokol görünmelidir.

İyi sonuç nasıl görünür? Zincir sunucunun gönderdiği ara sertifikalarla doğrulanır, sertifika sunduğunuz her adı kapsar, bağlantı TLS 1.3 veya 1.2 kullanır, yenileme otomatiktir ve işletim belgesi sorumluyu belirtir. Sertifika otoritesine bağlı olmayan bir süre bitiş uyarısı vardır.

Olağan çözüm. Yenilemeyi ACME ile otomatikleştirin. Let’s Encrypt, ACME Renewal Information (ARI) kullanmayı ya da sertifika ömrünün yaklaşık üçte ikisinde yenilemeyi önerir; sertifikalar 45 gün sürdüğünde sabit 60 günlük yenileme aralığının artık yetmeyeceği konusunda da uyarır. Taşımadan sonra yeni platformun gerçekten yenilediğini doğrulayın. Tek bir el sıkışma yalnızca anlaşılan protokolü gösterir; TLS 1.0 ve 1.1’in kapalı olduğunu doğrulamak için desteklenen tüm sürümleri listeleyen bir tarama aracı kullanın.

Bir HTTPS ziyareti sırasında sertifikanın, HSTS’nin ve tarayıcının diğer korumalarının nasıl birlikte çalıştığını HTTPS’in nasıl çalıştığı rehberinde bulabilirsiniz.

5. HTTPS yönlendirmesi: HTTPS’e tek adım, tek canonical ana makine, ardından HSTS

Neden önemli? Eski bağlantılar, yer imleri, betikler ve eski istemciler hâlâ http:// adreslerini ister. Yönlendirme onları HTTPS’e taşır, ancak hstspreload.org’un belirttiği gibi yol üstündeki bir saldırgan bu yönlendirmeyi yakalayıp değiştirebilir. HSTS, ilk güvenli ziyaretten sonraki her ziyaret için bu boşluğu kapatır.

Nasıl kontrol edilir?

curl -sI http://example.com/
curl -sI http://www.example.com/
curl -sIL "http://example.com/page?x=1" | grep -iE '^(HTTP|location)'

İyi sonuç nasıl görünür?

• MDN’in TLS rehberinin önerdiği gibi, aynı ana makinede HTTPS üzerindeki aynı yola kalıcı yönlendirme (301 veya istek yöntemini korumak için 308); ardından canonical ana makineye en fazla bir adım daha. Yol ve sorgu dizesi korunur.
• HTTPS yanıtı Strict-Transport-Security gönderir. Tarayıcılar düz HTTP üzerindeki başlığı yok sayar; yönlendirmenin kendisinde buna gerek yoktur.
• Karışık içerik yok: tarayıcılar HTTPS sayfalarında http:// üzerinden yüklenen betikleri engeller.

Olağan çözüm. Yönlendirmeyi JavaScript’te değil, sunucuda veya CDN’de yapın. HSTS max-age değerini aşamalı olarak 31536000 (bir yıl) gibi uzun bir değere çıkarın; includeSubDomains’i yalnızca her alt alan adı HTTPS sunuyorsa ekleyin. hstspreload.org artık HSTS’yi önermekte, ancak preload’u önermemektedir. Sertifikalar ACME HTTP-01 doğrulamasını kullanıyorsa 80 portunu erişilebilir tutun. Bu maddeyi Yayına Hazırlık Snapshot’ı ile sınamak için http:// adresini girin; çıplak alan adı veya https:// adresiyle bunun yerine HSTS max-age ve karışık içerik kontrol edilir.

6. Güvenlik başlıkları: son yanıtı ve hata sayfalarını kontrol edin

Neden önemli? Güvenlik başlıkları tarayıcıya bir sayfanın neleri yükleyebileceğini, kimin çerçeveleyebileceğini ve içerik türlerine nasıl davranılacağını söyler. Çoğu zaman sunucu veya CDN yapılandırmasında bulunurlar; bu yüzden barındırma taşıması onları düşürebilir. Siteler arası betik çalıştırma (XSS) gibi hataların zararını sınırlarlar; hataları gidermezler.

Nasıl kontrol edilir?

curl -sIL https://example.com/
curl -sI https://example.com/no-such-page

Hata sayfasını da kontrol edin: OWASP HTTP Başlıkları Rehberi’nin belirttiği gibi, always parametresi olmadan nginx add_header değerlerini yalnızca bazı durum kodlarıyla gönderir.

İyi sonuç nasıl görünür? Basit bir site için makul bir başlangıç kümesi:

Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

• CSP’yi önce Content-Security-Policy-Report-Only olarak devreye alın. Sayfalarınızın meşru olarak yüklediği her şeye izin vermelidir; 'unsafe-inline' amacının büyük bölümünü boşa çıkarır.
• frame-ancestors, default-src’den miras almaz ve <meta> etiketinde yok sayılır; X-Frame-Options: DENY daha eski yedek yöntemdir.
• Oturum çerezleri Secure, HttpOnly ve açık bir SameSite taşır (bkz. MDN Set-Cookie). HttpOnly, sayfadaki betiklerin çerezi okumasını (örneğin document.cookie ile) engeller; ancak tarayıcı çerezi eşleşen isteklerle yine gönderir. Bu yüzden XSS üzerinden çerez hırsızlığını sınırlar, XSS’in kendisini önlemez.
• X-XSS-Protection başlığı yok ya da 0 olarak ayarlı.

Olağan çözüm. Başlıkları tek katmanda (sunucu, uygulama veya CDN) ayarlayın; böylece hata sayfaları dahil her yanıt her başlığı tam olarak bir kez alır. Güvenlik başlıkları kontrol rehberi her başlığı ayrıntılı açıklar; ücretsiz güvenlik başlıkları kontrolü herkese açık bir sitenin ana sayfasındaki sekiz temel başlığı değerlendirir; hata sayfalarını yukarıdaki gibi curl ile kontrol edin.

7. Teknoloji bilgisi ifşası, önbellek ve sıkıştırma

Teknoloji bilgisi ifşası

Neden önemli? Server, X-Powered-By ve generator etiketleri hangi yazılımı çalıştırdığınızı herkese söyler; MDN, ayrıntılı sürüm numaralarının bilinen güvenlik açıklarını bulmayı kolaylaştırabileceğini belirtir. Bunları gizlemek koruma değil hijyendir: OWASP test rehberi bunu belirsizlik yoluyla güvenlik olarak adlandırır, MDN ise yama uygulamayı daha sağlam yaklaşım sayar.

Nasıl kontrol edilir? curl -sI https://example.com/ | grep -iE '^(server|x-powered-by):' çalıştırın; ardından sayfa kaynağında generator ve sürüm numarası içeren betik dosya adlarını arayın.

İyi sonuç nasıl görünür? Sürüm numarasız Server: nginx ve X-Powered-By yok.

Olağan çözüm. nginx’te server_tokens off;, php.ini’de expose_php = Off, Express’te app.disable('x-powered-by'). Bir sayfa eskimiş bir kütüphaneyi ele veriyorsa onu gizlemek yerine güncelleyin.

Önbellek, sıkıştırma ve CDN

Neden önemli? Önbellek kuralları, bir yanıtın saklanan kopyasını kimin alacağına karar verir. CDN tarafından önbelleğe alınan kişisel bir sayfa sonraki ziyaretçiye sunulabilir; MDN bu yüzden kişiselleştirilmiş yanıtların Cache-Control: private gerektirdiğini söyler.

Nasıl kontrol edilir? curl -sI -H 'Accept-Encoding: br, gzip' https://example.com/ çalıştırın, ardından giriş yapıp bir hesap sayfası açın ve yanıt başlıklarını tarayıcının geliştirici araçlarında okuyun.

İyi sonuç nasıl görünür? HTML Content-Encoding: br veya gzip ile sunulur; her yanıtta açık bir Cache-Control vardır; uzun max-age ve immutable yalnızca sürümlenmiş statik dosyalarda kullanılır; kullanıcı verisi içeren sayfalarda private veya no-store bulunur (no-cache yine de saklamaya izin verir).

Olağan çözüm. Cache-Control’ü rota türüne göre ayarlayın, oturum açılmış yolları CDN önbelleğinin dışında tutun ve metni sunucuda veya CDN’de sıkıştırın. CDN’in olmaması tek başına risk değildir; hız konusunu web sitesi performans rehberi ele alır.

8. Alan adı kaydı: bitiş tarihi, kilit ve iletişim bilgileri

Neden önemli? .com gibi bir genel üst düzey alan adının süresi dolduğunda, ICANN’in Süresi Dolmuş Kayıt Kurtarma Politikası kayıt şirketinin bir süre DNS çözümlemesini durdurmasını şart koşar; böylece site ve e-posta birlikte çalışmaz olur. Yenileme hatırlatmaları kayıtlı iletişim kişisine gider; bu kişi eski bir çalışan veya süresi dolmak üzere olan alan adındaki bir posta kutusu olabilir.

Nasıl kontrol edilir? ICANN’in sorgulama aracını kullanın. 28 Ocak 2025’ten beri RDAP, genel üst düzey alan adları için kayıt verisinin kesin kaynağıdır; WHOIS yalnızca .com, .name ve .post için hâlâ zorunludur. Ülke kodlu alan adlarında kayıt kuruluşunun veya kayıt şirketinin kendi sorgusunu kullanın. Ardından kayıt şirketi hesabınıza girip ayarlarını kontrol edin.

İyi sonuç nasıl görünür?

• Bitiş aylar sonra, otomatik yenileme açık ve yenileme tarihinde hâlâ geçerli olacak bir ödeme yöntemi.
• clientTransferProhibited ayarlı, kayıt şirketi sunuyorsa güncelleme ve silme kilitleri de; alan adını DNS dışında tutan clientHold veya serverHold yok.
• Birden fazla kişiye ulaşan iletişim bilgileri, en az biri alan adının kendisinde olmayan bir adres ve kayıt şirketi hesabında çok etkenli giriş.

Olağan çözüm. Otomatik yenilemeyi açın, birkaç yıllığına yenileyin, kayıt şirketinden kilit durumlarını ayarlamasını isteyin (ICANN’in EPP durum kodu rehberi her birini açıklar) ve iletişim bilgilerini güncelleyin.

9. Bu kontrol listesinin kapsamadığı şeyler

Bu sekiz madde sitenizin çevresindeki herkese açık kurulumu anlatır. Bir site hepsinden geçip yine de kolayca ele geçirilebilir, çünkü hiçbiri uygulamaya veya nasıl işletildiğine bakmaz. Şunları ayrıca inceleyin:

• Uygulama açıkları: enjeksiyon, şablonlarınızdaki siteler arası betik çalıştırma, güvenli olmayan yüklemeler, hesaplar arası erişim.
• Kimlik doğrulama ve oturumlar: giriş, parola sıfırlama, çok etkenli doğrulama, yönetim panelleri.
• Bağımlılıklar ve sunucular: CMS eklentileri, paketler, işletim sistemi yamaları.
• Gizli anahtarlar ve erişim: depolardaki veya ön yüz paketlerindeki anahtarlar; üretime, DNS sağlayıcısına ve kayıt şirketine kimin erişebildiği.
• Yedekler: gerçekten sınadığınız bir geri yükleme.

Web sitesi güvenlik denetimi rehberi giriş, izinler ve diğer uygulama tarafı kontrollerini adım adım anlatır; OWASP Web Güvenliği Test Rehberi ayrıntılı test senaryoları sunar.

Tek origin üzerinde hızlı ilk geçiş. Ücretsiz Yayına Hazırlık Snapshot’ı hesap gerektirmez. Tek bir herkese açık origin için herkese açık DNS’i, e-posta DNS kayıtlarını, alan adı kayıt verisini, TLS el sıkışmasını ve ana sayfanın HTTP yanıtını okur; exploit, port taraması, giriş denemesi veya yük göndermez. Bir puan, sertleştirme notu, risk sinyali ve geçen kontrol sayıları ile ilk bakmanız gereken en fazla üç sinyal alırsınız. Pentest değildir: iyi bir puan, bu herkese açık sinyallerin o anda sağlıklı göründüğü anlamına gelir. Free plan yalnızca güvenlik kontrollerini kapsar; denetim kredileriyle bir Free çalışma alanı diğer alanlarda da tek tek denetim çalıştırabilir (her yeni Free çalışma alanı her alan için 1 krediyle başlar). Altı denetim alanının tamamı (güvenlik, teknik SEO, yapay zekâ görünürlüğü, erişilebilirlik, performans, entegrasyonlar) Starter planında $49/ay’dan itibaren dahildir.

Uygulamadaki akışın tamamını görmek isterseniz Stepthrough’un learn.ynteractive.com’da yayımladığı, gerçek ekranlarla hazırlanmış adım adım eğitime göz atabilirsiniz. Eğitim; site sahipliğini doğrulamayı, güvenlik, teknik SEO, yapay zekâ görünürlüğü, erişilebilirlik ve performans denetimlerini çalıştırmayı ve bulguları önceliklendirmeyi kapsar.