HSTS preload, alan adının tarayıcıların yerleşik HTTPS listesine eklenmesini sağlar. Böylece ilk ziyarette bile HTTP bağlantısı denenmez. Bunun karşılığında kök alanın bütün alt alanları için uzun vadeli HTTPS taahhüdü verilir.
Preload bir güvenlik puanı için açılacak basit bir seçenek değildir. Unutulmuş bir alt alan, dış sağlayıcıya delege edilmiş hizmet veya başarısız sertifika yenilemesi kullanıcıların siteye ulaşmasını engelleyebilir.
HSTS preload nedir?
Normal HSTS politikası, tarayıcı geçerli HTTPS yanıtını gördükten sonra kaydedilir. Preload listesinde ise alan daha ilk bağlantıdan önce HTTPS olarak bilinir. Başvuru için uzun max-age, includeSubDomainsve preloadyönergesi gerekir.
Gerçekçi bir WordPress örneği
Şirket ana WordPress sitesini preload listesine ekler; ancak legacy.example.comdış bir sağlayıcıda yalnız HTTP ile çalışmaktadır. includeSubDomainsnedeniyle tarayıcı bu hizmete HTTPS üzerinden bağlanır ve bağlantı başarısız olur.
Alan daha sonra listeden çıkarılsa bile güncellemenin tarayıcı sürümlerine ulaşması zaman alır. Bu süre boyunca sunucuda yapılan geri dönüş bütün kullanıcıları hemen kurtarmaz.
Avantajı ve kullanım koşulları
Preload, ilk HTTP isteğinin düşürme veya yönlendirme saldırısına açık olmasını önler. Fakat bu kazanım, alan adının tamamında olgun HTTPS yönetimi gerektirir. Bütün mevcut ve gelecekteki alt alanların HTTPS sunacağından emin değilseniz normal HSTS ile kalmak daha güvenlidir.
Başvuru öncesi adımlar
- DNS kayıtlarını, delege edilmiş alt alanları ve kullanılmayan eski hostları envantere alın.
- Her hostta geçerli sertifika ve otomatik yenilemeyi doğrulayın.
- HSTS’yi preload olmadan uzun süre işletip yenileme dönemini gözlemleyin.
includeSubDomainskapsamını ilgili iş birimleri ve altyapı ekipleriyle onaylayın.- Preload uygunluk testini çalıştırın ve kaldırma planını belgeleyin.
- Başvurunun sorumlusunu ve yeni DNS kaydı açma politikasını belirleyin.
İleri teknik kontroller
DNS geçmişini, wildcard ve delege edilmiş zone’ları, üçüncü taraf SaaS hostlarını ve afet kurtarma alanlarını inceleyin. Her alt alanda sertifika kapsamını, IPv4/IPv6 bağlantısını ve otomatik yenilemeyi sınayın. Preload durumunu temsilî tarayıcı listelerinde takip edin.
Yeni alt alan oluşturma sürecine HTTPS kurulumunu ve sertifika yenilemesinden sorumlu ekibin açıkça belirlenmesini ekleyin. Preload kararı yalnız WordPress ekibinin değil, alan adını kullanan bütün ekiplerin sorumluluğudur.
Riskler ve kaldırma
Preload, bilinmeyen veya gelecekte açılacak alt alanları da etkiler. Dış sağlayıcı sözleşmesi sona ererse veya sertifika yenilemesi bozulursa HTTP’ye geçici dönüş mümkün değildir. Kaldırma talebi verilebilir; ancak liste ve istemci güncellemeleri anlık değildir.
AIOWS nasıl yardımcı olur?
AIOWS SSL Yöneticisi
Preload değerlendirmesinde AIOWS SSL Yöneticisi, ana WordPress sitesinin HTTPS ve desteklenen HSTS ayarları bakımından hazır olup olmadığını incelemeye yardımcı olur.
Preload kararı yalnız WordPress ayarlarına dayanamaz. AIOWS bütün DNS alanlarını, dış sağlayıcı sözleşmelerini veya tarayıcı preload listelerini yönetmez. Alt alan envanteri, sertifika yenilemesi ve her hizmetten sorumlu ekip ayrı ayrı doğrulanmalıdır.
WordPress tarafında belirsiz HTTPS, yönlendirme veya sertifika sorunu varsa preload başvurusunu erteleyin. Önce normal HSTS’yi güvenle işletin; başvuruyu ancak bir ekip alanın tamamını uzun vadede işletme sorumluluğunu açıkça üstlendiğinde yapın.
AIOWS SSL Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress’te HSTS Güvenle Nasıl Etkinleştirilir?
- WordPress SSL Sertifikası ve HTTPS Sağlığı Nasıl Kontrol Edilir?
- WordPress HTTPS Canonical URL ve Site Haritası Ayarları
Sonuç ve önerilen yol
Preload’u yalnızca bütün alt alanlarda sürdürülebilir HTTPS, otomatik sertifika yenilemesi ve alanın tamamı için açıkça tanımlanmış kurumsal sorumluluk varsa seçin. Bu güvence yoksa doğru yapılandırılmış normal HSTS daha güvenli ve geri alınabilir bir tercihtir.
