HTTP güvenlik başlıkları nedir? CSP, HSTS ve diğerleri nasıl eklenir?

HTTP güvenlik başlıkları, sunucunun her yanıtla birlikte tarayıcıya gönderdiği ve tarayıcının sayfayı nasıl işleyeceğini sınırlayan talimatlardır. HSTS bağlantıyı HTTPS'e kilitler, Content-Security-Policy hangi kaynaktan script yüklenebileceğini belirler, X-Content-Type-Options, Referrer-Policy ve Permissions-Policy ise tür tahmini, referans bilgisi ve cihaz izinlerini kısıtlar. Başlıklar sunucu yapılandırmasında, .htaccess dosyasında veya Cloudflare kurallarıyla eklenir.

HTTP güvenlik başlıkları neden gereklidir?

HTTP güvenlik başlıkları, kodda bir açık olsa bile saldırının tarayıcıda işe yaramasını zorlaştıran ikinci bir savunma katmanıdır. Siteler arası betik çalıştırma (XSS), tıklama kaçırma (clickjacking), HTTPS'ten HTTP'ye düşürme ve gereksiz veri sızıntısı gibi riskler, doğru başlıklarla sunucu tarafında birkaç satırlık ayarla belirgin biçimde azaltılabilir.

Bu başlıklar SSL sertifikasının veya düzenli güncellemenin yerini tutmaz; onları tamamlar. Sertifika bağlantıyı şifreler, güncellemeler bilinen açıkları kapatır, güvenlik başlıkları ise tarayıcıya sayfanızın neye izin verip neye vermediğini söyler. Başlıca başlıklar şunlardır:

• —Strict-Transport-Security (HSTS): tarayıcıyı alan adına yalnızca HTTPS ile bağlanmaya zorlar.
• —Content-Security-Policy (CSP): script, stil, görsel ve bağlantı kaynaklarını beyaz listeyle sınırlar.
• —X-Content-Type-Options: nosniff değeriyle tarayıcının dosya türünü tahmin etmesini engeller.
• —Referrer-Policy: başka sitelere geçerken hangi adres bilgisinin paylaşılacağını belirler.
• —Permissions-Policy: kamera, mikrofon, konum gibi tarayıcı özelliklerine erişimi kapatır.
• —frame-ancestors / X-Frame-Options: sayfanızın başka sitelerde iframe içine alınmasını engeller.

HSTS nasıl eklenir ve preload listesine girerken nelere dikkat edilmeli?

HSTS, Strict-Transport-Security başlığıyla eklenir ve tarayıcıya belirli bir süre boyunca alan adına yalnızca HTTPS ile bağlanmasını söyler. Güvenli yol, önce kısa bir max-age değeriyle (örneğin 300 saniye) başlamak, tüm alt alan adlarının HTTPS çalıştığını doğruladıktan sonra süreyi bir yıla çıkarmak ve preload'u en sona bırakmaktır.

• —Başlangıç: Strict-Transport-Security: max-age=300
• —Doğrulama sonrası: max-age=31536000; includeSubDomains
• —Preload için hstspreload.org koşulları: en az bir yıllık max-age, includeSubDomains ve preload ifadesi.
• —Preload listesi tarayıcılara gömülür; listeden çıkmak aylar sürebilir, bu yüzden HTTPS'i olmayan tek bir alt alan adı (ör. eski bir mail paneli) bile erişilemez hale gelir.

HSTS yalnızca HTTPS yanıtlarında dikkate alınır; HTTP yanıtına eklenen başlık yok sayılır. Bu nedenle önce HTTP'den HTTPS'e 301 yönlendirmesinin kusursuz çalıştığından emin olun.

Content-Security-Policy siteyi bozmadan nasıl devreye alınır?

Content-Security-Policy siteyi bozmadan devreye almanın yolu, önce Content-Security-Policy-Report-Only başlığıyla yalnızca raporlama yapan bir politika yayınlamak, tarayıcı konsolundaki ve rapor adresindeki ihlalleri birkaç hafta toplamak ve politikayı gerçek kaynak listesine göre daralttıktan sonra zorlayıcı moda geçmektir. Doğrudan zorlayıcı CSP, analitik ve form gibi parçaları sessizce kırabilir.

En sık sorun satır içi (inline) scriptlerdir. Google Ads veya Google Analytics için sayfanın head bölümüne eklenen gtag kodu satır içi bir scripttir ve katı bir CSP bunu engeller. Üç seçenek vardır:

• —Nonce: her yanıtta rastgele üretilen bir değer script etiketine ve başlığa eklenir. Sunucu tarafında dinamik üretim gerektirir; tamamen statik dosya sunan sitelerde ancak bir edge katmanıyla mümkündür.
• —Hash: satır içi scriptin içeriğinin SHA-256 özeti ('sha256-...') politikaya yazılır. Statik ve prerender edilmiş sitelere en uygun yöntemdir; script içeriği bir karakter bile değişirse hash yenilenmelidir.
• —'unsafe-inline': en kolay ama korumayı büyük ölçüde zayıflatan yol; yalnızca geçici bir ara adım olarak düşünülmelidir.
• —Google etiketleri için script-src, img-src ve connect-src içine googletagmanager.com, google-analytics.com ve Google Ads alan adlarını eklemek gerekir; Google'ın resmi CSP kılavuzundaki güncel listeyi kullanın.

Makul bir başlangıç politikası default-src 'self' ile başlar, ardından kullanılan her dış kaynak açıkça eklenir. object-src 'none' ve base-uri 'self' eklemek de düşük maliyetli, yüksek faydalı iki ayardır.

X-Content-Type-Options, Referrer-Policy ve Permissions-Policy ne işe yarar?

X-Content-Type-Options, Referrer-Policy ve Permissions-Policy, neredeyse hiçbir siteyi bozmadan eklenebilen üç düşük riskli başlıktır. nosniff tarayıcının dosya türünü tahmin etmesini engeller, Referrer-Policy dış sitelere giden adres bilgisini sınırlar, Permissions-Policy ise sitenin kullanmadığı kamera, mikrofon ve konum gibi özellikleri tamamen kapatır.

• —X-Content-Type-Options: nosniff
• —Referrer-Policy: strict-origin-when-cross-origin (dış sitelere yalnızca alan adı gider, tam yol gitmez)
• —Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()
• —X-XSS-Protection artık modern tarayıcılarda desteklenmiyor; eklemeyin veya 0 değerini kullanın.

frame-ancestors mı, X-Frame-Options mı?

Clickjacking'e karşı modern yöntem CSP'nin frame-ancestors 'self' yönergesidir; X-Frame-Options: SAMEORIGIN ise eski tarayıcılar için eklenir. İkisi birlikte kullanıldığında modern tarayıcılar frame-ancestors'ı esas alır. frame-ancestors, meta etiketiyle tanımlanan CSP'de çalışmaz; mutlaka HTTP başlığı olarak gönderilmelidir.

Güvenlik başlıkları nerede tanımlanır: sunucu, .htaccess mi Cloudflare mi?

Güvenlik başlıkları sunucu yapılandırmasında, Apache uyumlu sunucularda .htaccess dosyasında veya Cloudflare gibi bir CDN'de yanıt başlığı kurallarıyla tanımlanabilir. Önemli olan tek bir yer seçmek ve başlığın gerçekten kullanıcıya ulaşan yanıtta göründüğünü doğrulamaktır; iki katmanda aynı başlık tanımlanırsa çakışma ve tekrar oluşabilir.

• —Apache / .htaccess: mod_headers ile Header always set X-Content-Type-Options "nosniff"
• —Nginx: add_header X-Content-Type-Options "nosniff" always;
• —OpenLiteSpeed: WebAdmin panelinde sanal sunucu bağlamındaki başlık ayarları; .htaccess desteği Apache ile birebir aynı değildir.
• —Cloudflare: Rules altında Transform Rules > Modify Response Header ile tüm yanıtlara başlık eklenir; HSTS için SSL/TLS > Edge Certificates bölümündeki ayar da kullanılabilir.

Kendi sitemiz OpenLiteSpeed üzerinde, Cloudflare arkasında çalışıyor. Bu barındırmada bazı .htaccess direktiflerinin statik dosyalarda beklendiği gibi uygulanmadığını deneyimle gördük. Buradan çıkan ders şu: hangi katmanı seçerseniz seçin, yapılandırmaya değil yanıta bakarak doğrulayın.

Güvenlik başlıklarında en sık yapılan hatalar nelerdir?

Güvenlik başlıklarında en sık yapılan hatalar, internetten kopyalanan katı bir CSP'yi test etmeden zorlayıcı modda yayınlamak, HSTS preload'u alt alan adlarını kontrol etmeden açmak ve aynı başlığı hem sunucuda hem CDN'de tanımlayıp çelişen değerler üretmektir. Bu hataların çoğu, kademeli geçiş ve yanıt üzerinden doğrulama ile önlenir.

• —CSP'yi yalnızca ana sayfada test edip ödeme, form veya harita içeren sayfaları unutmak.
• —Yeni bir analitik, canlı destek veya video aracı eklerken CSP listesini güncellememek.
• —Satır içi script içeriği değiştiği halde eski hash değerini politikada bırakmak.
• —Aynı başlığı iki katmanda tanımlayıp tarayıcıya iki farklı değer göndermek.
• —Yalnızca HTML yanıtlarına başlık ekleyip hata sayfalarını (404, 500) atlamak.

Güvenlik başlıkları nasıl test edilir?

Güvenlik başlıkları, securityheaders.com gibi ücretsiz tarayıcı araçları, MDN HTTP Observatory, tarayıcı geliştirici araçlarındaki Network sekmesi ve komut satırında curl -I komutuyla test edilir. Harf notu hızlı bir özet verir, ama asıl doğrulama farklı sayfa türlerinde başlıkların gerçekten göründüğünü ve konsolda CSP ihlali olmadığını görmektir.

• —Ana sayfa, bir iç sayfa, bir görsel ve bir JS dosyası için ayrı ayrı curl -I çalıştırın.
• —DevTools > Network > ilgili istek > Headers bölümünde yanıt başlıklarını kontrol edin.
• —Console sekmesinde 'Content Security Policy' uyarılarını arayın; Report-Only döneminde bunlar listenizin hammaddesidir.
• —Form gönderimini, analitik olaylarını ve dönüşüm etiketlerini test ederek hiçbir işlevin kırılmadığını doğrulayın.
• —Her büyük güncellemeden sonra testi tekrarlayın; yeni bir üçüncü taraf script CSP'yi kırabilir.