HSTS, doğru kullanıldığında HTTPS güvenliğini güçlendiren etkili bir tarayıcı politikasıdır. Ancak özellikle alt alan adları, test ortamları ve farklı servislerin aynı alan adı altında çalıştığı yapılarda hatalı bir HSTS ayarı erişim sorunlarına yol açabilir. Bir kullanıcı tarayıcısı bu politikayı öğrendiğinde, belirlenen süre boyunca ilgili alan adına yalnızca HTTPS üzerinden bağlanmaya çalışır; bu davranış bazı alt alan adlarını beklenmedik şekilde kilitleyebilir.
HSTS ne yapar ve neden kritik kabul edilir?
HSTS, yani HTTP Strict Transport Security, tarayıcıya “bu alan adına bundan sonra yalnızca HTTPS ile bağlan” talimatı verir. Bu sayede kullanıcı yanlışlıkla HTTP adresine gitse bile tarayıcı isteği HTTPS’e çevirir. Man-in-the-middle saldırılarına karşı ek koruma sağlar ve kurumsal web sitelerinde güvenlik standardının önemli bir parçasıdır.
Sorun, bu talimatın kapsamı yanlış belirlendiğinde ortaya çıkar. HSTS başlığı yalnızca ana alan adını değil, isteğe bağlı olarak tüm alt alan adlarını da etkileyebilir. Özellikle hosting tarafında birden fazla uygulama, panel, CDN, e-posta arayüzü veya test subdomain’i kullanılıyorsa bu ayar dikkatle planlanmalıdır.
Alt alan adlarını kilitleyen ayar: includeSubDomains
HSTS başlığında en riskli parametrelerden biri includeSubDomains değeridir. Bu parametre etkinleştirildiğinde tarayıcı, ana alan adıyla birlikte tüm alt alan adlarının da HTTPS kullanması gerektiğini kabul eder.
Örneğin aşağıdaki politika yayınlandığında, sadece example.com değil; panel.example.com, test.example.com, api.example.com ve henüz yayına alınmamış tüm alt alan adları da etkilenir:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadBu noktada test.example.com üzerinde geçerli bir SSL sertifikası yoksa veya servis yalnızca HTTP ile çalışıyorsa, kullanıcı tarayıcıdan bu adrese erişemez. Daha da önemlisi, tarayıcı güvenlik nedeniyle kullanıcıya “devam et” seçeneği sunmayabilir. Bu durum çoğu zaman yanlışlıkla “site çöktü” ya da “DNS bozuldu” şeklinde yorumlanır.
HSTS kilitlenmesi nasıl fark edilir?
HSTS kaynaklı bir problemde DNS kayıtları doğru, sunucu ayakta ve servis çalışıyor olabilir. Buna rağmen tarayıcı HTTPS bağlantısını zorladığı için erişim başarısız olur. Aşağıdaki belirtiler HSTS ihtimalini güçlendirir:
- Alt alan adı HTTP ile çalışacak şekilde tasarlanmıştır ancak tarayıcı otomatik olarak HTTPS’e yönlenir.
- SSL sertifikası olmayan subdomain’lerde güvenlik hatası alınır.
- Farklı tarayıcıda veya gizli sekmede davranış değişebilir.
- curl gibi araçlarla HTTP yanıtı alınırken tarayıcı erişimi engelleyebilir.
- HSTS süresi uzun verildiyse sorun günlerce veya aylarca devam edebilir.
Yanlış yapılandırmanın en sık görüldüğü senaryolar
Test ve geliştirme alt alan adları
Kurumsal ekipler çoğu zaman dev.example.com veya staging.example.com gibi alt alan adlarında geçici ortamlar kurar. Ana alan adına includeSubDomains ile HSTS verildiyse bu ortamların da geçerli SSL sertifikasına sahip olması gerekir. Aksi halde geliştiriciler, test kullanıcıları veya müşteri ekipleri erişim problemi yaşar.
Farklı sunucularda çalışan servisler
Ana web sitesi modern bir HTTPS yapısıyla çalışırken bazı alt servisler farklı bir sunucu üzerinde yer alabilir. Eski bir kontrol paneli, özel API, raporlama ekranı veya cihaz arayüzü HTTPS desteği olmadan çalışıyorsa HSTS bu servisleri devre dışı bırakmış gibi gösterebilir.
Preload listesine erken başvuru
HSTS preload, alan adının tarayıcılar tarafından önceden HTTPS zorunlu listesine alınmasıdır. Güvenlik açısından güçlüdür ancak geri dönüşü hızlı değildir. Preload listesine girmeden önce tüm alt alan adlarının HTTPS’e hazır olduğundan emin olunmalıdır. Hazırlık yapılmadan başvuru yapmak, ileride açılacak subdomain’leri bile etkileyebilir.
Güvenli HSTS geçişi nasıl planlanmalı?
HSTS’i doğrudan uzun süreli ve tüm alt alan adlarını kapsayacak şekilde açmak yerine kademeli ilerlemek daha güvenlidir. İlk aşamada düşük bir max-age değeriyle test yapılabilir. Örneğin birkaç dakika veya birkaç saatlik sürelerle davranış izlenir; ardından gün, hafta ve yıl seviyesine çıkılır.
Pratik bir geçiş planı şu şekilde olabilir:
- Önce tüm aktif alt alan adlarının envanterini çıkarın.
- Her subdomain için geçerli SSL sertifikası bulunduğunu doğrulayın.
- HTTP’den HTTPS’e yönlendirmelerin tutarlı çalıştığını test edin.
- İlk aşamada includeSubDomains kullanmadan HSTS’i deneyin.
- Log kayıtlarında sertifika, yönlendirme ve erişim hatalarını izleyin.
- Alt alan adları hazır değilse preload başvurusu yapmayın.
Yanlış HSTS ayarı yapıldıysa ne yapılabilir?
HSTS başlığı sunucudan kaldırılabilir veya max-age=0 olarak yayınlanabilir. Bu, tarayıcıya ilgili HSTS kaydını silme talimatı verir. Ancak kullanıcı tarayıcısının bu yeni başlığı alabilmesi için ilgili alan adına başarılı şekilde bağlanabilmesi gerekir. Eğer sertifika hatası bağlantıyı tamamen engelliyorsa süreç zorlaşabilir.
Tarayıcı bazında HSTS kayıtları manuel temizlenebilir; fakat bu yalnızca tekil kullanıcılar için geçici bir çözümdür. Kurumsal ölçekte yapılması gereken, etkilenen tüm alt alan adlarına geçerli sertifika tanımlamak ve HTTPS yapılandırmasını düzeltmektir. Özellikle paylaşımlı hosting kullanılan ortamlarda kontrol paneli, DNS, SSL ve yönlendirme ayarlarının birlikte incelenmesi gerekir.
Uygulamadan önce kontrol edilmesi gereken teknik noktalar
HSTS kararını vermeden önce yalnızca ana web sitesine bakmak yeterli değildir. Wildcard sertifika kullanılıp kullanılmadığı, CDN’in HSTS başlığı ekleyip eklemediği, ters proxy veya load balancer katmanında farklı başlıkların gönderilip gönderilmediği kontrol edilmelidir. Aynı başlığın birden fazla katmanda farklı değerlerle verilmesi de beklenmeyen davranışlara neden olabilir.
En sağlıklı yaklaşım, HSTS’i bir güvenlik anahtarı gibi değil, altyapı politikası gibi ele almaktır. Alan adı altında bugün çalışan ve ileride açılması planlanan servisler HTTPS’e hazır değilse includeSubDomains ve preload değerleri ertelenmelidir. Böylece güvenlik seviyesi yükseltilirken erişilebilirlik, operasyon sürekliliği ve kullanıcı deneyimi korunmuş olur.