Bir web sitesinin HTTPS üzerinden açılması, tarayıcı ile sunucu arasındaki bağlantının şifrelenmesine yardımcı olur. Ancak güvenli bağlantı kullanılması, tarayıcının yüklediği JavaScript dosyalarının, üçüncü taraf içeriklerin veya sayfa gömme işlemlerinin otomatik olarak güvenli olduğu anlamına gelmez.
HTTP güvenlik başlıkları, web sunucusunun tarayıcıya gönderdiği ek kurallarla bu alanlarda kontrol sağlar. Doğru yapılandırılmış başlıklar, belirli içerik enjeksiyonu risklerinin azaltılmasına, HTTPS kullanımının güçlendirilmesine ve sayfaların yetkisiz biçimde başka sitelere gömülmesinin sınırlandırılmasına yardımcı olabilir.
Bununla birlikte her web sitesi için kullanılabilecek tek bir güvenlik başlığı yapılandırması bulunmaz. Özellikle Content Security Policy (CSP) gibi politikalar, uygulamanın kullandığı kaynaklara göre hazırlanmalıdır. Kontrol edilmeden uygulanan katı kurallar, meşru içeriklerin yüklenmesini engelleyebilir.
HTTP Güvenlik Başlıkları Nedir?
HTTP güvenlik başlıkları (HTTP Security Headers), web sunucusunun HTTP yanıtlarıyla birlikte tarayıcıya ilettiği güvenlik politikalarıdır.
Tarayıcı bir web sayfası istediğinde sunucu yalnızca HTML içeriği göndermez. Yanıtın durum kodu, içerik türü, önbellekleme bilgileri ve çeşitli güvenlik kuralları da HTTP başlıklarında bulunabilir.
Örneğin bir sunucu şu başlığı gönderebilir:
X-Content-Type-Options: nosniffBu başlık, tarayıcının sunucunun bildirdiği içerik türünü dikkate almasını ve bazı durumlarda içerik türünü tahmin ederek değiştirmemesini sağlar.
Başlıklar genellikle Apache, Nginx, CDN, ters proxy veya uygulama katmanında yapılandırılabilir.
Ancak aynı başlığın birden fazla katmanda farklı değerlerle gönderilmesi beklenmeyen sonuçlara neden olabilir. Bu nedenle güvenlik politikalarının hangi bileşen tarafından yönetildiği açık olmalıdır.
En Önemli HTTP Güvenlik Başlıkları Hangileridir?
Web uygulamalarında sık kullanılan başlıkların işlevleri birbirinden farklıdır.
| Güvenlik başlığı | Temel amacı |
|---|---|
| Content-Security-Policy | Yüklenebilecek içerik kaynaklarını ve bazı tarayıcı davranışlarını sınırlandırır. |
| Strict-Transport-Security | Tarayıcıya belirli süre boyunca HTTPS kullanmasını bildirir. |
| X-Content-Type-Options | MIME türü tahmininden kaynaklanabilecek bazı riskleri azaltır. |
| Referrer-Policy | Başka isteklere aktarılabilecek yönlendiren sayfa bilgisini kontrol eder. |
| X-Frame-Options | Sayfanın iframe içerisinde gösterilmesini sınırlandırır. |
| Permissions-Policy | Belirli tarayıcı özelliklerinin kullanımına ilişkin kurallar tanımlar. |
Bu başlıkların hepsini herhangi bir değerlendirme yapmadan etkinleştirmek doğru değildir.
Örneğin dış kaynaklı JavaScript dosyaları kullanan bir sitede çok kısıtlayıcı CSP politikası işlev kaybına neden olabilir. Benzer şekilde bütün alt alan adlarında HTTPS hazır değilse HSTS’nin includeSubDomains seçeneği erişim sorunları oluşturabilir.
Bu nedenle güvenlik başlıkları, uygulamanın gerçek ihtiyaçları ve tarayıcı uyumluluğu dikkate alınarak yapılandırılmalıdır.
Content Security Policy (CSP) Nedir?
Content Security Policy, web sayfasının hangi kaynaklardan içerik yükleyebileceğini ve belirli içerik türlerinin nasıl çalıştırılacağını sınırlandıran tarayıcı güvenlik mekanizmasıdır.
CSP’nin önemli kullanım alanlarından biri, Cross-Site Scripting (XSS) saldırılarının etkisini azaltmaktır.
XSS, saldırganın bir web uygulamasına zararlı istemci tarafı kodu enjekte edebilmesiyle ortaya çıkan güvenlik açığı sınıfıdır.
CSP, uygun şekilde hazırlandığında tarayıcının yetkisiz kaynaklardan betik çalıştırmasını veya belirli içerikleri yüklemesini engelleyebilir.
Ancak CSP, uygulama kodundaki güvenlik açıklarını otomatik olarak düzeltmez. Girdi doğrulama, çıktı kodlama ve güvenli uygulama geliştirme yöntemleri yine gereklidir.
MDN’nin Content Security Policy referansı politika yönergelerini ve uygulama davranışlarını ayrıntılı biçimde açıklar.
CSP nasıl çalışır?
Örnek bir CSP politikası:
Content-Security-Policy: default-src 'self'; object-src 'none'; base-uri 'self'Bu örnekte:
default-src 'self', ilgili kaynak türleri için varsayılan olarak aynı origin üzerinden yüklemeye izin verir.object-src 'none', object ve embed gibi eski eklenti içeriklerini engeller.base-uri 'self', belgenin temel URL adresinin hangi kaynaklardan belirlenebileceğini sınırlar.
Bu yapılandırma, her web sitesine doğrudan uygulanabilecek evrensel bir şablon değildir.
Özellikle CDN, analiz servisi, harici font, ödeme entegrasyonu veya inline JavaScript kullanan uygulamalarda ek kurallar gerekebilir.
CSP’de script-src neden önemlidir?
script-src, JavaScript kaynaklarını ve bazı betik çalıştırma davranışlarını kontrol eder.
Örneğin:
Content-Security-Policy: script-src 'self'Bu politika, yalnızca aynı origin üzerinden yüklenen betiklere izin vermeyi amaçlar.
Ancak sayfada kullanılan inline JavaScript kodları, uygun nonce veya hash mekanizması bulunmadığında engellenebilir.
Modern CSP yapılandırmalarında nonce veya hash tabanlı yaklaşımlar, geniş kapsamlı unsafe-inline izinlerine göre daha güçlü koruma sağlayabilir.
Özellikle dinamik uygulamalarda nonce değerinin her HTTP yanıtı için güvenli şekilde üretilmesi ve ilgili betiklerle eşleştirilmesi gerekir.
Statik bir nonce değerini bütün sayfalarda tekrar kullanmak doğru değildir.
CSP Report-Only modu ne işe yarar?
Yeni bir CSP politikası doğrudan zorunlu hale getirilmeden önce raporlama modunda denenebilir.
Örneğin:
Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'Bu başlık, ihlalleri gözlemlemek için kullanılır; tek başına ilgili kaynakları engellemez.
Tarayıcı geliştirici araçlarının konsolunda politika ihlalleri görülebilir. Ayrıca uygun bir raporlama uç noktası yapılandırılarak ihlal raporları toplanabilir.
Raporlama sırasında kişisel veya hassas bilgilerin gereksiz yere kaydedilmemesine dikkat edilmelidir.
CSP’nin kademeli olarak devreye alınması, özellikle çok sayıda eklenti veya üçüncü taraf entegrasyonu kullanan sitelerde önemlidir.
HSTS Nedir ve HTTPS Güvenliğini Nasıl Etkiler?
HTTP Strict Transport Security (HSTS), tarayıcıya belirli bir alan adına gelecekte yalnızca HTTPS üzerinden bağlanması gerektiğini bildiren güvenlik mekanizmasıdır.
Örnek başlık:
Strict-Transport-Security: max-age=300Bu örnekte max-age=300, tarayıcının politikayı 300 saniye boyunca hatırlamasını sağlar.
HSTS başlığı, geçerli HTTPS yanıtı üzerinden alındığında anlam kazanır. HTTP üzerinden gönderilen HSTS başlığı tarayıcı tarafından dikkate alınmaz.
HSTS, HTTP’den HTTPS’ye yönlendirme kuralıyla aynı şey değildir. Yönlendirme sunucu tarafından gerçekleştirilirken HSTS, politikayı öğrenmiş tarayıcının sonraki bağlantılarını HTTPS üzerinden başlatmasını sağlar.
includeSubDomains seçeneği ne yapar?
HSTS yapılandırmasına şu seçenek eklenebilir:
Strict-Transport-Security: max-age=31536000; includeSubDomainsBu durumda politika, ilgili alan adının alt alan adlarını da kapsar.
Ancak mail, panel, api veya farklı hizmetler için kullanılan alt alan adlarının tamamında uygun HTTPS yapılandırması bulunmuyorsa erişim sorunları oluşabilir.
Bu nedenle includeSubDomains etkinleştirilmeden önce bütün alt alan adlarının durumu değerlendirilmelidir.
HSTS preload kullanılmalı mı?
HSTS preload, belirli alan adlarının tarayıcıların önceden yüklenmiş HSTS listelerine dahil edilmesini sağlayan mekanizmadır.
Bu yaklaşım ilk bağlantıda HTTP kullanımından doğabilecek bazı riskleri azaltabilir.
Ancak preload süreci uzun vadeli operasyonel sorumluluk oluşturur. Alan adının ve ilgili alt alan adlarının HTTPS gereksinimlerini sürekli karşılaması gerekir.
Bu nedenle yalnızca güvenlik taramasında daha yüksek puan almak amacıyla preload eklemek uygun değildir.
MDN’nin HSTS dokümantasyonu, başlığın tarayıcı davranışını ve yapılandırma seçeneklerini açıklar.
HSTS uygulanmadan önce HTTPS sertifikası ve yönlendirmeleri doğru çalışmalıdır. Plesk kullanan sistemlerde temel hazırlık için Plesk üzerinde SSL sertifikası kurulumu rehberi incelenebilir.
X-Content-Type-Options Nedir?
X-Content-Type-Options, tarayıcının sunucu tarafından bildirilen MIME türünü dikkate almasını sağlayan HTTP güvenlik başlığıdır.
Yaygın kullanım şekli:
X-Content-Type-Options: nosniffMIME türü, bir dosyanın veya HTTP yanıtının içerik biçimini belirtir.
Örneğin JavaScript dosyaları için uygun JavaScript MIME türü, CSS dosyaları için ise text/css kullanılması gerekir.
nosniff etkinleştirildiğinde tarayıcı, belirli kaynak türlerinde yanlış MIME bilgisiyle sunulan içerikleri engelleyebilir.
Bu yaklaşım, kullanıcı tarafından yüklenen veya yanlış içerik türüyle sunulan dosyaların beklenmeyen biçimde yorumlanmasından kaynaklanabilecek bazı riskleri azaltır.
Ancak sunucunun doğru Content-Type başlıkları göndermesi yine gereklidir.
Yanlış MIME yapılandırmasına sahip bir sitede nosniff etkinleştirilmesi, JavaScript veya CSS dosyalarının yüklenmesini engelleyebilir.
Bu nedenle değişiklik sonrasında tarayıcı konsolunda MIME hataları kontrol edilmelidir.
X-Frame-Options ve Clickjacking Koruması
Clickjacking, kullanıcının başka bir sayfa veya arayüz içinde gösterilen içeriğe farkında olmadan etkileşimde bulunmasını hedefleyen saldırı yaklaşımıdır.
X-Frame-Options, web sayfasının iframe gibi gömme mekanizmalarıyla başka sayfalarda görüntülenmesini sınırlandırabilir.
Örnek:
X-Frame-Options: SAMEORIGINBu değer, sayfanın aynı origin kapsamında iframe içerisinde kullanılmasına izin verirken farklı origin’lerde gömülmesini sınırlandırır.
Daha katı seçenek:
X-Frame-Options: DENYBu durumda sayfanın iframe içerisinde gösterilmesi engellenir.
Ancak gömülü ödeme sayfaları, yönetim arayüzleri veya üçüncü taraf entegrasyonlar kullanan sistemlerde bu ayarlar işlev kaybına neden olabilir.
CSP frame-ancestors ile farkı
Modern uygulamalarda CSP’nin frame-ancestors yönergesi daha ayrıntılı kontrol sağlayabilir.
Örnek:
Content-Security-Policy: frame-ancestors 'self'Bu politika, sayfanın hangi üst sayfalar tarafından gömülebileceğini belirler.
frame-ancestors yönergesi, default-src tarafından otomatik olarak kapsanmaz; açıkça tanımlanmalıdır.
Ayrıca bu yönerge CSP meta etiketi üzerinden değil, HTTP yanıt başlığı üzerinden uygulanmalıdır.
Referrer-Policy Nedir?
Bir kullanıcı web sayfasından başka bir adrese geçtiğinde tarayıcı, isteğin hangi sayfadan kaynaklandığına ilişkin bilgi gönderebilir.
Bu bilgi Referer başlığında taşınır.
Referrer-Policy, bu bilginin hangi kapsamda paylaşılacağını kontrol eder.
Örnek politika:
Referrer-Policy: strict-origin-when-cross-originBu politika, aynı origin içindeki isteklerde daha ayrıntılı referer bilgisine izin verirken farklı origin’lere yapılan güvenli isteklerde yalnızca origin bilgisinin gönderilmesini sağlar. HTTPS’den HTTP’ye geçişlerde ise referer bilgisi gönderilmez.
Bu değer modern tarayıcılarda yaygın varsayılan davranıştır.
Daha katı bir seçenek:
Referrer-Policy: no-referrerBu politika referer bilgisinin gönderilmesini engeller.
Ancak bazı analiz, yönlendirme veya entegrasyon süreçleri referer bilgisine ihtiyaç duyabilir.
Bu nedenle politika seçimi uygulamanın gereksinimlerine göre yapılmalıdır.
Permissions-Policy Ne İşe Yarar?
Permissions-Policy, belirli tarayıcı özelliklerinin belge veya gömülü içerikler tarafından kullanımını kontrol etmek için kullanılan HTTP yanıt başlığıdır.
Örneğin bir web uygulaması konum bilgisi veya kamera erişimi gerektirmiyorsa ilgili özellikler sınırlandırılabilir.
Örnek:
Permissions-Policy: camera=(), microphone=(), geolocation=()Bu politika, belirtilen özelliklerin ilgili belge kapsamında kullanılmasını engeller.
Ancak görüntülü görüşme, konum tabanlı hizmet veya mikrofon erişimi kullanan uygulamalarda bu ayarların doğrudan uygulanması işlev kaybına neden olur.
Ayrıca tarayıcı desteği ve politika davranışı kullanılan özelliğe göre değişebilir.
Apache Üzerinde HTTP Güvenlik Başlıkları Nasıl Eklenir?
Apache web sunucusunda HTTP yanıt başlıkları mod_headers modülü aracılığıyla yönetilebilir.
Sunucu yapılandırmasına erişim varsa başlıkların sanal sunucu yapılandırmasında yönetilmesi tercih edilebilir.
Paylaşımlı hosting ortamlarında ise sağlayıcının izin verdiği koşullarda .htaccess dosyası kullanılabilir.
.htaccess dosyasının genel kullanım alanları Apache .htaccess yapılandırması rehberinde açıklanmaktadır.
Apache için örnek yapılandırma
Aşağıdaki örnek, Apache 2.4 ve etkin mod_headers modülü bulunan bir ortam içindir:
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>Bu yapılandırma üç farklı güvenlik başlığı ekler.
Ancak mevcut uygulama veya üst sunucu yapılandırması aynı başlıkları gönderiyorsa tekrar eden ya da çelişen başlıklar oluşabilir.
Özellikle Apache’de always ve varsayılan başlık tablolarının farklı davranışları bulunabildiğinden, değişiklik sonrasında gerçek HTTP yanıtları kontrol edilmelidir.
Önemli: Örnek, tüm sitelerde doğrudan uygulanacak bir güvenlik profili değildir. İframe kullanan uygulamalarda SAMEORIGIN uygun olmayabilir.
HSTS Apache üzerinde nasıl eklenir?
HTTPS yapılandırması doğrulanmış bir sanal sunucuda başlangıç testi için:
Header always set Strict-Transport-Security "max-age=300"Bu başlık yalnızca HTTPS yanıtlarında gönderilmelidir.
HSTS’nin HTTP sanal sunucusuna eklenmesi istenen güvenlik davranışını sağlamaz.
Ayrıca test süresinin ardından daha uzun süreli politika uygulanmadan önce sertifika yenileme, alt alan adları ve geri dönüş senaryoları değerlendirilmelidir.
Apache yapılandırması nasıl doğrulanır?
Sunucu yönetim yetkisi bulunan ortamlarda:
apachectl configtestkomutu yapılandırmanın sözdizimini kontrol etmek için kullanılabilir.
Bazı dağıtımlarda komut adı veya yolu farklı olabilir.
Bu kontrol yapılandırmanın bütün uygulama işlevleriyle uyumlu olduğunu garanti etmez.
Paylaşımlı hosting kullanıcıları genellikle sistem genelindeki Apache yapılandırmasını değiştiremez. Bu durumda panelin izin verdiği yöntemler kullanılmalıdır.
Nginx Üzerinde HTTP Güvenlik Başlıkları Nasıl Eklenir?
Nginx web sunucusunda güvenlik başlıkları add_header yönergesiyle tanımlanabilir.
Örnek:
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;Bu yönergeler uygun server veya location bağlamına yerleştirilmelidir.
Nginx yapılandırmasında alt bağlamlarda tanımlanan add_header yönergeleri, üst bağlamdan miras alınan başlıkları etkileyebilir. Bu davranış kullanılan Nginx sürümüne ve yapılandırma seçeneklerine göre değerlendirilmelidir.
Bu nedenle başlıkları yalnızca tek bir yapılandırma dosyasında görmek yeterli değildir; gerçek yanıtın incelenmesi gerekir.
Nginx yapılandırmasını test etme
Sunucu yönetim yetkisi bulunan Linux ortamlarında:
sudo nginx -tkomutu yapılandırmanın sözdizimini ve temel geçerliliğini kontrol eder.
Test başarılıysa uygun bakım prosedürüyle yapılandırma yeniden yüklenebilir:
sudo systemctl reload nginxBu ikinci komut canlı web sunucusunun yapılandırmasını yeniden yükler.
Hatalı bir yapılandırma erişim sorunlarına neden olabileceği için değişiklikten önce çalışan yapılandırmanın yedeği alınmalı ve geri dönüş yöntemi hazırlanmalıdır.
WordPress Sitelerinde Güvenlik Başlıkları Nasıl Yönetilmeli?
WordPress sitelerinde güvenlik başlıkları birden fazla katmandan gönderilebilir:
- Web sunucusu
- CDN veya ters proxy
- Hosting kontrol paneli
- WordPress güvenlik eklentisi
- Özel uygulama kodu
Bu katmanlardan hangisinin başlıkları yönettiği bilinmeden yeni kurallar eklemek, yinelenen veya çelişen politikalar oluşturabilir.
Özellikle CSP yapılandırması WordPress sitelerinde dikkat gerektirir.
Tema dosyaları, sayfa oluşturucular, analiz servisleri, reklam kodları, harici fontlar ve ödeme entegrasyonları farklı kaynaklardan içerik yükleyebilir.
Bu nedenle WordPress üzerinde CSP uygulanırken önce kullanılan kaynaklar envanter haline getirilmeli, ardından Report-Only modunda test yapılmalıdır.
Gereksiz geniş izinler eklemek yerine hangi kaynağın neden gerekli olduğu belirlenmelidir.
Örneğin bütün harici kaynaklara sınırsız izin veren bir CSP politikası, başlık mevcut olsa bile beklenen güvenlik faydasını önemli ölçüde azaltabilir.
HTTP Güvenlik Başlıkları Nasıl Test Edilir?
Başlıklar eklendikten sonra gerçek HTTP yanıtlarında görünüp görünmedikleri kontrol edilmelidir.
curl ile başlıkları görüntüleme
Linux, macOS veya curl kurulu Windows ortamlarında:
curl -I https://ornekalanadi.com/Bu komut HTTP HEAD isteği göndererek yanıt başlıklarını görüntüler.
Örnek alan adı gerçek site adresiyle değiştirilmelidir.
Ancak bazı web uygulamaları HEAD ve GET isteklerine farklı yanıtlar verebilir.
Bu nedenle gerekli durumlarda GET isteğinin yanıt başlıkları da incelenmelidir:
curl -sS -D - -o /dev/null https://ornekalanadi.com/Bu komut sayfa gövdesini kaydetmeden yanıt başlıklarını gösterir.
Tarayıcı geliştirici araçlarıyla kontrol
Chrome, Firefox ve benzeri tarayıcılarda geliştirici araçları açılarak Network panelinden ilgili isteğin yanıt başlıkları incelenebilir.
Özellikle şu noktalar kontrol edilmelidir:
- Beklenen güvenlik başlıkları mevcut mu?
- Aynı başlık birden fazla kez gönderiliyor mu?
- CSP ihlalleri konsolda görünüyor mu?
- JavaScript ve CSS kaynakları yükleniyor mu?
- Ödeme ve giriş işlemleri çalışıyor mu?
- İframe kullanan entegrasyonlar etkileniyor mu?
Yalnızca ana sayfayı test etmek yeterli olmayabilir. Yönetim paneli, oturum açma ekranı, ödeme sayfası ve farklı alt alan adları da değerlendirilmelidir.
HTTP Güvenlik Başlıkları ile WAF Arasındaki Fark
HTTP güvenlik başlıkları ile Web Application Firewall (WAF) farklı görevler üstlenir.
Güvenlik başlıkları, tarayıcının içerik yükleme ve sayfa işleme davranışlarını kontrol etmeye yardımcı olur.
WAF ise HTTP isteklerini analiz ederek belirli saldırı desenlerini veya kötü amaçlı trafiği filtrelemeyi amaçlar.
Örneğin CSP, tarayıcıda yetkisiz bir betiğin çalışmasını engellemeye yardımcı olabilir. WAF ise uygulamaya gelen belirli zararlı istekleri tespit edip engelleyebilir.
Benzer şekilde HTTP güvenlik başlıkları, yüksek hacimli trafik saldırılarını durdurmak için tasarlanmamıştır.
Bu tür tehditler DDoS ve uygulama katmanı saldırıları kapsamında değerlendirilir.
Hostider’ın Layer 7 DDoS ve WAF koruması da bu ayrı güvenlik katmanına yönelik bir hizmettir.
Güvenlik başlıkları, WAF, uygulama güvenliği, güncelleme yönetimi ve erişim kontrolleri birbirinin yerine geçmez. Gereksinime göre birlikte kullanılabilecek tamamlayıcı önlemlerdir.
Güvenlik Başlıkları Yanlış Yapılandırılırsa Ne Olur?
Yanlış yapılandırılan güvenlik başlıkları uygulamanın bazı işlevlerini engelleyebilir.
JavaScript dosyaları yüklenmiyor
CSP’nin script-src veya default-src yönergeleri kullanılan JavaScript kaynaklarına izin vermiyor olabilir.
Tarayıcı konsolundaki CSP ihlal mesajları incelenmelidir.
CSS dosyaları engelleniyor
CSP’nin style-src politikası veya yanlış MIME türü, CSS kaynaklarının yüklenmesini etkileyebilir.
Bu durumda yalnızca CSP değil, sunucunun gönderdiği Content-Type bilgisi de kontrol edilmelidir.
Ödeme veya harici entegrasyon çalışmıyor
Üçüncü taraf ödeme sağlayıcıları iframe, JavaScript veya harici bağlantılar kullanabilir.
CSP’nin frame-src, connect-src ve diğer ilgili yönergeleri entegrasyonun gereksinimlerine göre değerlendirilmelidir.
HSTS sonrasında siteye erişilemiyor
Tarayıcı HSTS politikasını hatırlıyorsa geçersiz HTTPS sertifikası veya erişilemeyen HTTPS hizmeti ciddi erişim sorunlarına neden olabilir.
HSTS’nin geri alınması, daha önce politikayı önbelleğe almış tarayıcılarda hemen sonuç vermeyebilir.
Bu nedenle HSTS önce kısa süreli politikayla test edilmeli, ardından kontrollü biçimde genişletilmelidir.
Güvenlik Başlıklarında Güvenli Geri Dönüş Planı
Üretim ortamında başlık değişikliği yapılmadan önce mevcut yapılandırma yedeklenmelidir.
Apache .htaccess veya Nginx yapılandırma dosyaları için önceki çalışan sürüm korunmalıdır.
CSP ile ilgili sorunlarda Report-Only yaklaşımına geri dönmek veya yeni zorlayıcı politikayı kaldırmak değerlendirilebilir.
Ancak CSP’nin birden fazla katmandan gönderilmesi halinde yalnızca tek bir başlığı kaldırmak yeterli olmayabilir.
HSTS için geri dönüş daha dikkatli planlanmalıdır.
Örneğin geçerli HTTPS yanıtında:
Strict-Transport-Security: max-age=0gönderilmesi, ilgili HSTS politikasının tarayıcı tarafından kaldırılmasını sağlayabilir.
Ancak bunun için tarayıcının ilgili HTTPS yanıtına ulaşabilmesi gerekir. Ayrıca üst alan adından gelen includeSubDomains politikaları veya preload listesi nedeniyle etkiler devam edebilir.
Bu nedenle HSTS, kolayca geri alınabilen sıradan bir yapılandırma değişikliği gibi değerlendirilmemelidir.
Sıkça Sorulan Sorular
HTTP güvenlik başlıkları SSL sertifikasının yerini tutar mı?
Hayır. TLS/HTTPS bağlantı güvenliği sağlar. HTTP güvenlik başlıkları ise tarayıcı davranışlarını ve belirli içerik politikalarını kontrol eder. İki mekanizma farklı amaçlara hizmet eder.
Her web sitesinde CSP kullanılmalı mı?
CSP birçok uygulamada yararlı olabilir. Ancak politikanın uygulamaya uygun hazırlanması gerekir. Yanlış veya gereğinden geniş CSP yapılandırması beklenen korumayı sağlamayabilir.
HSTS site hızını artırır mı?
HSTS’nin temel amacı performans değil güvenliktir. Tarayıcıların belirli HTTP yönlendirme adımlarını atlamasına yardımcı olabilse de her sitede ölçülebilir hız artışı garanti edilmez.
WordPress güvenlik eklentisi başlık eklemek için yeterli mi?
Bazı eklentiler güvenlik başlıklarını yönetebilir. Ancak web sunucusu, CDN ve eklenti yapılandırmalarının birbiriyle uyumlu olması gerekir. Eklentinin başlık eklemesi tek başına doğru politika uygulandığını kanıtlamaz.
X-XSS-Protection kullanılmalı mı?
Bu başlık eski tarayıcıların XSS filtreleriyle ilişkilidir ve modern güvenlik yaklaşımında temel koruma yöntemi olarak önerilmez. Uygun CSP, güvenli uygulama geliştirme ve doğru çıktı kodlama yöntemleri tercih edilmelidir.
Security Headers testinden yüksek puan almak sitenin tamamen güvenli olduğu anlamına gelir mi?
Hayır. Başlık testleri belirli tarayıcı güvenlik politikalarını değerlendirir. SQL injection, yetkilendirme hataları, sunucu açıkları veya güncel olmayan yazılımlar gibi riskleri bütünüyle kapsamaz.
Sonuç
HTTP güvenlik başlıkları, web uygulamalarının tarayıcı tarafındaki güvenlik davranışlarını kontrol etmek için önemli araçlardır.
CSP içerik kaynaklarını sınırlandırırken HSTS HTTPS kullanımını güçlendirir. X-Content-Type-Options içerik türlerinin doğru yorumlanmasına, Referrer-Policy bilgi paylaşımının kontrolüne, X-Frame-Options ve CSP frame-ancestors ise sayfa gömme davranışlarının sınırlandırılmasına yardımcı olur.
Ancak güvenli yapılandırmanın temel koşulu, başlıkları rastgele eklemek değil uygulamanın ihtiyaçlarına göre planlamaktır.
Özellikle CSP ve HSTS politikaları önce kontrollü ortamda test edilmeli, gerçek HTTP yanıtları incelenmeli ve gerektiğinde geri dönüş uygulanabilecek şekilde yönetilmelidir.
Bu yaklaşım, web sunucusu ve uygulama güvenliği önlemlerinin birbirini tamamladığı daha sürdürülebilir bir güvenlik mimarisi oluşturulmasına katkı sağlar.
