HSTS preload listesine girmeden önce hangi riskler değerlendirilmelidir?

HSTS preload listesine dahil olmak, bir alan adının tarayıcılar tarafından en baştan yalnızca HTTPS üzerinden açılmasını sağlar. Bu güçlü bir güvenlik avantajıdır; ancak yanlış planlandığında erişim kesintisi, alt alan adı sorunları ve geri dönüşü zor operasyonel riskler doğurabilir. Özellikle kurumsal web sitelerinde karar yalnızca güvenlik ekibinin değil, DNS, sertifika, uygulama, CDN ve hosting altyapısını yöneten ekiplerin ortak değerlendirmesiyle verilmelidir.

HSTS preload nedir ve neden dikkat ister?

HSTS, tarayıcıya belirli bir süre boyunca siteye sadece HTTPS ile bağlanmasını söyleyen bir güvenlik başlığıdır. Preload listesi ise bu kuralın tarayıcıya siteye ilk girişten önce gömülü olarak gelmesini sağlar. Böylece kullanıcı daha önce siteyi hiç ziyaret etmemiş olsa bile HTTP bağlantısı denenmez.

Bu yapı, ortadaki adam saldırılarını ve yanlış yönlendirme risklerini azaltır. Ancak preload listesine giriş, sıradan bir yapılandırma değişikliği değildir. Alan adı listeye eklendiğinde tarayıcılar bu tercihi uzun süre korur; hatalı bir sertifika, eksik HTTPS yapılandırması veya unutulmuş bir alt alan adı doğrudan erişim problemine dönüşebilir.

Teknik ön koşullar eksiksiz sağlanmalı

Preload başvurusu yapılmadan önce ana alan adı ve tüm alt alan adları HTTPS üzerinden sorunsuz çalışmalıdır. Sadece ana web sitesinin yeşil kilit göstermesi yeterli değildir. API servisleri, panel adresleri, test ortamları, eski kampanya sayfaları ve üçüncü taraflara yönlenen subdomainler ayrıca incelenmelidir.

HSTS başlığı doğru yapılandırılmalı

Preload için genellikle şu parametreler beklenir: max-age değerinin yeterince uzun olması, includeSubDomains ifadesinin kullanılması ve preload direktifinin eklenmesi. Örnek başlık şu şekildedir:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Buradaki en kritik ifade includeSubDomains bölümüdür. Bu ifade, yalnızca ana alan adını değil, tüm alt alan adlarını da HTTPS zorunluluğuna dahil eder. Eğer herhangi bir subdomain hâlâ HTTP kullanıyorsa veya geçerli sertifikaya sahip değilse, preload sonrası erişilemez hale gelebilir.

Alt alan adları en büyük risk alanıdır

Kurumsal yapılarda yıllar içinde oluşturulmuş çok sayıda alt alan adı bulunabilir. Bazıları aktif kullanılmasa bile DNS üzerinde kayıtlı kalabilir. Örneğin eski bir bayi portalı, geçici bir test sunucusu ya da sadece belirli ofislerden erişilen iç uygulama gözden kaçabilir.

Başvuru öncesi tüm DNS kayıtları çıkarılmalı, her bir alt alan adı için HTTPS erişimi test edilmeli ve gereksiz kayıtlar temizlenmelidir. Dış hizmet sağlayıcıya yönlenen subdomainlerde ise karşı tarafın SSL sertifikası, yönlendirme davranışı ve yenileme süreçleri ayrıca doğrulanmalıdır.

Sertifika yönetimi ve yenileme süreci

HSTS preload kullanıldığında sertifika hatalarına tolerans azalır. Süresi dolmuş, yanlış alan adına düzenlenmiş veya ara sertifika zinciri eksik bir SSL sertifikası kullanıcı tarafında sert uyarılara neden olur. Tarayıcı, HTTP’ye geri dönerek siteyi açma seçeneği sunmaz.

Bu nedenle sertifika yenileme otomatikleştirilmeli, yenileme başarısızlıkları için izleme kurulmalı ve sorumlu ekipler netleştirilmelidir. Çok alan adlı veya wildcard sertifikalarda kapsam düzenli olarak kontrol edilmelidir. Hosting sağlayıcısının otomatik SSL yenileme, yedekleme ve bildirim kabiliyetleri bu aşamada karar verici olabilir.

Geri dönüş süreci hızlı değildir

Preload listesinden çıkmak mümkündür ancak etkisi hemen görülmez. Liste güncellense bile tarayıcıların yeni sürümleri kullanıcılara farklı zamanlarda ulaşır. Bu da hatalı bir kararın haftalarca veya aylarca etkisini sürdürebileceği anlamına gelir.

Bu nedenle preload, “deneyelim, olmazsa kaldırırız” mantığıyla uygulanmamalıdır. Önce HSTS başlığı preload olmadan devreye alınmalı, kısa ve orta vadeli gözlem yapılmalı, loglar incelenmeli ve beklenmeyen HTTP istekleri tespit edilmelidir.

CDN, proxy ve yönlendirme katmanları kontrol edilmeli

Web sitesi bir CDN, yük dengeleyici veya ters proxy arkasında çalışıyorsa HTTPS davranışı uçtan uca test edilmelidir. Kullanıcı tarayıcısı ile CDN arasında HTTPS varken, CDN ile origin sunucu arasında HTTP kullanılması güvenlik beklentisini zayıflatabilir.

Ayrıca HTTP’den HTTPS’ye yapılan 301 yönlendirmeler tek adımda ve tutarlı olmalıdır. Zincirleme yönlendirmeler, yanlış canonical yapıları ve karışık içerik sorunları hem kullanıcı deneyimini hem de arama motoru taramasını olumsuz etkileyebilir.

Uygulama ve içerik bağımlılıkları incelenmeli

Sayfa içindeki görsel, CSS, JavaScript, iframe veya API çağrılarının HTTP üzerinden gelmesi karışık içerik uyarılarına yol açabilir. Modern tarayıcılar bazı pasif içerikleri yükseltebilir; ancak aktif içerikler engellenebilir. Bu durum form gönderimleri, ödeme adımları veya kullanıcı paneli gibi kritik akışları bozabilir.

Canlıya almadan önce staging ortamında tarayıcı konsolu, güvenlik başlıkları, form akışları ve üçüncü taraf entegrasyonları kontrol edilmelidir. Özellikle ödeme servisleri, CRM entegrasyonları, harici fontlar ve analitik etiketleri HTTPS uyumluluğu açısından test edilmelidir.

Karar öncesi pratik kontrol listesi

• Tüm ana ve alt alan adları HTTPS ile sorunsuz açılıyor mu?
• Geçersiz, unutulmuş veya dış sağlayıcıya bağlı subdomain var mı?
• SSL sertifikaları otomatik yenileniyor ve izleniyor mu?
• CDN, proxy ve origin katmanlarında HTTPS tutarlı mı?
• Uygulamada karışık içerik veya HTTP API çağrısı bulunuyor mu?
• Preload olmadan HSTS belirli bir süre test edildi mi?
• Acil durumda sorumlular, erişim yetkileri ve müdahale planı hazır mı?

Kurumsal karar için önerilen yaklaşım

HSTS preload, güvenlik olgunluğu yüksek ve alan adı envanteri kontrol altında olan kurumlar için değerli bir adımdır. Buna karşılık hızlı alınmış bir karar, güvenlik kazanımından çok operasyonel kesinti üretebilir. En sağlıklı yöntem; önce envanter çıkarmak, test süresi tanımlamak, izleme kurmak ve ardından başvuruyu yapmaktır.

Özellikle çok markalı, çok dilli veya çok lokasyonlu yapılarda her alan adı aynı anda preload kapsamına alınmak zorunda değildir. Kritik alanlar önceliklendirilebilir, riskli alt alan adları temizlenebilir ve altyapı hazır oldukça kapsam genişletilebilir. Böylece güvenlik seviyesi yükselirken kullanıcı erişimi, SEO görünürlüğü ve iş sürekliliği korunmuş olur.