Güvenlik başlıkları kontrolü: eksik HTTP güvenlik başlıklarını bulma ve düzeltme

1. Başlıklarınızı kendiniz kontrol edin: DevTools ve curl

Chrome veya Edge’de DevTools’u açın, Network panelini seçin ve sayfayı yeniden yükleyin. İlk isteğe (HTML belgesi) tıklayın, Headers sekmesini açın ve Response Headers bölümüne inin. Sayfa yüklemeleri ve yönlendirmeler arasında istekleri korumak için Preserve log, önbellekteki yanıt yerine taze yanıt almak için Disable cache seçeneğini işaretleyin (Chrome DevTools ağ başvurusu). Firefox’taki Network Monitor de aynı şekilde çalışır.

Terminalde curl sunucunun gönderdiği şeyi olduğu gibi yazdırır:

curl -sS -D - -o /dev/null https://example.com/

Yönlendirmeleri izleyip her adımın başlıklarını görmek için -L ekleyin. Windows’ta curl.exe çağırın ve -o NUL kullanın. curl -I daha kısadır ancak GET yerine HEAD isteği gönderir; bazı uygulamalar HEAD’i farklı bir kod yolunda işler, bu yüzden bulduklarınızı bir GET ile doğrulayın.

Aynı kontrolü http:// adresi (HTTPS’e 301 veya 308 yönlendirmesiyle yanıt vermeli), diğer ana makine adı (www veya çıplak alan adı), var olmayan bir sayfa, bir oturum açma sayfası, bir API yanıtı ve bir statik dosya için de yineleyin. Uygulama, web sunucusu ve CDN çoğu zaman bunların her birinde farklı başlıklar ekler ve yalnızca tarayıcıya ulaşan değerler sayılır.

2. Her başlık ne yapar ve başlamak için güvenli değer

nosniff ile tarayıcı bildirilen Content-Type değerine güvenir ve yanlış türle gelen betik ve stil dosyalarını engeller; bu yüzden açmadan önce bu türleri kontrol edin. Referrer-Policy başlığı olmasa da güncel tarayıcılar zaten strict-origin-when-cross-origin kullanır; OWASP yine de eski tarayıcılar için açıkça göndermeyi önerir, dayandığınız hiçbir şey referrer’a ihtiyaç duymuyorsa no-referrer daha katıdır. Permissions-Policy’de () bir özelliği sayfada ve içindeki her çerçevede devre dışı bırakır; bir özelliğe yalnızca ona ihtiyaç duyan bileşenin origin’i için izin verin. COOP same-origin değeri çapraz köken sızıntı saldırılarına (XS-Leaks) karşı yardımcı olur ancak başka bir origin’den sunulan oturum açma veya ödeme açılır pencerelerini bozabilir.

3. Content-Security-Policy ve frame-ancestors

CSP, tarayıcıya bir sayfanın betikleri, stilleri, görselleri, çerçeveleri ve bağlantıları nereden yükleyebileceğini söyler. Enjekte edilen betiğin yapabileceklerini sınırlar; girdiyi kaçışlamanın ve doğrulamanın yerini tutmaz. MDN CSP rehberi, izin verilen ana makinelerin uzun listesi yerine her yanıt için yeni bir nonce’a veya hash’lere dayanan bir katı CSP önerir. 'unsafe-inline' amacın büyük bölümünü boşa çıkarır ve tarayıcı, nonce veya hash içeren herhangi bir yönergede bunu yok sayar. Katı bir politikayı zorlaştıran genellikle etiket yöneticileri ve sohbet bileşenleri gibi başka betikler yükleyen üçüncü taraf kodlardır; bu yüzden eklediğiniz her istisnanın nedenini yazın.

default-src, script-src gibi fetch yönergeleri için yedektir ama frame-ancestors için değildir: default-src 'none' politikası bile herhangi bir sitenin sayfayı çerçeveye almasına izin verir. frame-ancestors 'self' değerini ya da X-Frame-Options: DENY değerine benzeyen 'none' değerini açıkça ayarlayın (MDN). OWASP HTTP Başlıkları Rehberi, frame-ancestors’ın onu destekleyen tarayıcılarda X-Frame-Options’ı gereksiz kıldığını, X-Frame-Options’ın ise eski tarayıcıları hâlâ kapsadığını söyler; ikisini de gönderiyorsanız aynı çerçevelemeye izin vermelerini sağlayın. İki tuzak: frame-ancestors, report-only politika ve X-Frame-Options bir <meta> etiketinde etkisizdir; X-Frame-Options: ALLOW-FROM ise modern tarayıcıların tüm başlığı yok saymasına yol açar.

Üçüncü taraf betiği olmayan bir site için ilk taslak, OWASP Secure Headers Project’in önerdiği politikadır:

default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; upgrade-insecure-requests

Satır içi betikleri, stilleri ve diğer ana makinelerden yüklenen her şeyi engeller; bu yüzden başlangıçta çok sayıda rapor bekleyin. Bu nedenle Report-Only olarak başlar (bölüm 8). Yalnızca CSP satırını alın: projenin tam kümesi, Cache-Control: no-store ve Clear-Site-Data gibi değerleri de içerir; bunlar önbelleği kapatır ve her yanıtta ziyaretçinin çerezlerini ve saklanan verilerini temizler. Tarayıcının işlemediği JSON API yanıtlarında CSP’nin etkisi azdır.

4. HSTS: max-age’i kademeli artırın, preload’u iki kez düşünün

Strict-Transport-Security, tarayıcıya ana makine için yalnızca HTTPS kullanmasını ve sonraki http:// isteklerini otomatik olarak yükseltmesini söyler. Tarayıcılar başlık düz HTTP üzerinden geldiğinde onu yok sayar; bu yüzden HTTP’den HTTPS’e yönlendirmede değil, HTTPS yanıtlarında gönderin. Tek başına, ziyaretçinin ilk bağlantısını koruyamaz.

Maliyeti hesaba katın: HSTS’li bir ana makinede ziyaretçiler sertifika hatalarını geçemez, dolayısıyla süresi dolan bir sertifika geri dönen ziyaretçileri dışarıda bırakır. 15 Mart 2026’dan itibaren verilen genel TLS sertifikaları en fazla 200 gün geçerli olabilir (CA/Browser Forum) ve Let’s Encrypt artık süre dolumu e-postası göndermiyor; bu yüzden önce otomatik yenilemeyi ve kendi süre izlemenizi kurun. SSL/TLS ve güvenlik başlıkları rehberi sertifika tarafını ele alır.

max-age değerini (saniye cinsinden) hstspreload.org’un önerdiği gibi kademeli artırın ve her adımda bozulma olup olmadığına bakın: 300 (5 dakika), 604800 (1 hafta), 2592000 (1 ay), ardından 31536000 (1 yıl) veya 63072000 (2 yıl, OWASP’ın kullandığı değer). max-age=0 politikayı kaldırır, ancak yalnızca HTTPS üzerinden gönderildiğinde ve yalnızca geri gelip bunu alan ziyaretçiler için. Her alt alan adı HTTPS üzerinden çalıştığında includeSubDomains ekleyin ve her alt alan adının da kendi başlığını göndermesini sağlayın.

Preload, alan adınızı tarayıcılara gömer; böylece ilk ziyaret bile HTTPS kullanır. Başvuru sitesi hstspreload.org artık HSTS’yi önerip preload’u önermiyor: Chrome ve Safari HTTP gezinmelerini zaten HTTPS’e yükseltiyor, bu yüzden preload az şey katar ve listeden çıkarılma kullanıcılara ulaşmak için aylar sürer. OWASP HTTP Başlıkları Rehberi örnek başlığında hâlâ preload içerir, OWASP Secure Headers Project’in önerilen değeri ise onu dışarıda bırakır. Varsayılan olarak eklemeyin ve bir şablondan kopyalamayın.

5. Çerez öznitelikleri: Secure, HttpOnly ve SameSite

Set-Cookie: __Host-session=…; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure, tarayıcının çerezi yalnızca HTTPS üzerinden göndermesini sağlar (localhost hariç). Çerezi JavaScript’ten gizlemez.
• HttpOnly, sayfadaki betiklerin çerezi okumasını engeller (örneğin document.cookie ile), ancak tarayıcı yine de eşleşen isteklerle birlikte gönderir; böylece XSS’in kendisini önlemeden XSS yoluyla çerez hırsızlığını sınırlar.
• SameSite, çerezin siteler arası isteklerle gidip gitmeyeceğini belirler. Strict ile asla gitmez. Lax ile başka bir siteden gelen üst düzey GET gezinmeleriyle de gider; örneğin ziyaretçinin sizin sitenize giden bir bağlantıyı izlemesi. None ile her zaman gider ve None için Secure gerekir. Tarayıcıların varsayılanları farklıdır, bu yüzden açıkça ayarlayın.
• __Host- ad öneki, çerez bir HTTPS origin’den Secure ile, Path=/ ile ve Domain özniteliği olmadan ayarlanmadıkça tarayıcının onu reddetmesini sağlar.

Bir akış gerçekten None gerektirmedikçe (örneğin başka bir siteden geri post eden ödeme veya oturum açma dönüşü) oturum çerezleri için Lax veya Strict kullanın. OWASP Oturum Yönetimi Rehberi, SameSite’ı siteler arası istek sahteciliğine (CSRF) karşı derinlemesine savunma olarak görür; CSRF belirteçlerinin yerine geçen bir önlem olarak değil.

6. Kaldırılacak başlıklar: X-XSS-Protection ve diğer kalıntılar

• X-XSS-Protection, eski tarayıcılarda kendisi XSS açıkları doğurabilen bir filtreyi açardı (MDN). OWASP bunu ayarlamamayı veya 0 ile kapatmayı söyler; yerine CSP geçer.
• Expect-CT: OWASP kullanılmamasını ve Mozilla’ya dayanarak mevcut yapılandırmalardan kaldırılmasını söyler.
• Public-Key-Pins (HPKP) 2018’de Chromium’dan kaldırıldı ve hiçbir modern tarayıcı tarafından desteklenmiyor.
• Feature-Policy’nin yerini Permissions-Policy aldı.

Server ve X-Powered-By yazılımınızı, bazen sürüm numaralarıyla birlikte, açığa vurur. OWASP bunları kaldırmayı veya bilgi vermez hâle getirmeyi önerir, ancak kendi test rehberi bunu belirsizlik yoluyla güvenlik olarak niteler ve MDN yazılımı güncel tutmanın daha önemli olduğunu söyler. Sürüm numaralarını kaldırın (nginx’te server_tokens off; başlığı değil sürümü kaldırır) ve emeği güncellemelere harcayın.

7. nginx ve statik barındırıcılar için kopyalanacak temel yapılandırma

Bu nginx temeli, düşük riskli başlıkları ayarlar, HSTS ve CSP’yi test aşamalarında başlatır ve HTTP’yi aynı ana makinede HTTPS’e yönlendirir. always parametresi başlıkları hata yanıtlarına da ekler.

server {
    listen 80;
    server_name example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name example.com;
    # ssl_certificate and ssl_certificate_key go here
    server_tokens off;

    add_header Strict-Transport-Security "max-age=300" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Cross-Origin-Opener-Policy "same-origin" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'" always;
}

nginx headers modülünün belgelenmiş iki davranışı, eksik başlıkların birçoğunu açıklar. always olmadan add_header yalnızca 200, 201, 204, 206, 301, 302, 303, 304, 307 ve 308 durum kodlarına uygulanır; bu yüzden 404 ve 500 sayfaları başlıksız çıkar. Ayrıca add_header yönergeleri, geçerli düzeyde hiç tanımlı değilse üst düzeyden devralınır: bir location bloğundaki tek bir add_header, orada sunucu düzeyindeki tüm güvenlik başlıklarını düşürür. Başlıkları tekrarlayın, ortak bir dosyayı include edin veya nginx 1.29.3’ten itibaren add_header_inherit merge; kullanın.

Cloudflare Pages ve Netlify gibi statik barındırıcılar, siteyle birlikte yayımlanan bir _headers dosyasını okur. Bu örnek, Netlify’ın da kullandığı Cloudflare’in belgelenmiş biçimini izler:

/*
  X-Content-Type-Options: nosniff
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()
  X-Frame-Options: SAMEORIGIN
  Content-Security-Policy-Report-Only: default-src 'self'; form-action 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'self'

Sınırları bilin. Cloudflare Pages dosyayı Pages Functions’ın ürettiği yanıtlara uygulamaz, en fazla 100 başlık kuralına ve satır başına en fazla 2.000 karaktere izin verir; aynı başlık iki kez uygulanırsa değerleri virgülle birleştirir. Netlify özel başlıkları yalnızca kendi sunduğu dosyalara uygular; proxy’lenen içeriğe, fonksiyonlara, edge fonksiyonlarına veya sunucuda üretilen sayfalara uygulamaz; bu yanıtlar kendi başlıklarını ayarlamalıdır. HSTS örneğin dışında bırakılmıştır: eklemeden önce platformun zaten ne gönderdiğini curl ile kontrol edin.

8. Kademeli devreye alın ve yaygın hatalardan kaçının

1. nosniff, Referrer-Policy, Permissions-Policy ve çerçeve korumasını ekleyin, ardından oturum açma, ödeme ve gömülü bileşenleri test edin.
2. Taslak CSP’yi Content-Security-Policy-Report-Only olarak gönderin. Hiçbir şey engellenmez; ihlaller tarayıcı konsolunda ve politika bir raporlama uç noktası belirtiyorsa orada görünür. Oturum açma arkasındaki sayfalar dahil temel yolculukları gezin ve politikayı ayarlayın.
3. HSTS’yi kısa bir max-age ile başlatın ve kademeli artırın.
4. CSP’yi zorunlu kılın. Bir sonraki sıkılaştırmayı denemek için daha katı bir Report-Only politikası yanında çalışabilir.
5. Her sunucu, CDN veya framework değişikliğinden sonra curl kontrollerini yeniden çalıştırın.

Yaygın hatalar:

• Başlıkların yalnızca bazı yanıtlarda olması. Ana sayfada vardır; 404 sayfasında, API’de, statik dosyalarda veya ayrı sunulan bir giriş sayfasında yoktur.
• Ana makineyi ve şemayı tek yönlendirmede değiştirmek. http://example.com doğrudan https://www.example.com adresine yönlendirirse tarayıcı example.com için HSTS’yi hiç almaz. Önce aynı ana makinede HTTPS’e yönlendirin, HSTS’yi o HTTPS yanıtında gönderin ve ancak sonra www’ya yönlendirin.
• CDN’in origin’i ezmesi. Bir CDN veya proxy başlık ekleyebilir, değiştirebilir, silebilir veya çoğaltabilir. Her başlığın hangi katmana ait olduğuna karar verin ve sonucu curl ile doğrulayın.
• Her şeye izin veren CSP. Hataları susturmak için 'unsafe-inline', 'unsafe-eval' veya * ile doldurulmuş bir politika varlık kontrolünden geçer ama çok az şeyi engeller.
• includeSubDomains’in çok erken eklenmesi. Yalnızca HTTP üzerinden çalışan unutulmuş bir alt alan adı, politikayı saklamış tarayıcılar için erişilemez olur.

Başlıklar bir katmandır. Web sitesi yayın kontrol listesi bunları DNS, TLS ve yönlendirmelerle yan yana ele alır; web sitesi güvenlik denetimi rehberi ise oturum açma, izinler ve tekrarlanabilir bir inceleme düzenini kapsar.

9. Ücretsiz Yayına Hazırlık Snapshot’ı başlıkları nasıl kontrol eder

Ücretsiz Yayına Hazırlık Snapshot’ı, kayıt gerektirmeden tek bir herkese açık origin üzerinde sekiz pasif kontrol çalıştırır; bunlardan biri HTTP güvenlik başlıklarını okur. Pentest değildir ve altı alanlı denetim de değildir.

• Girdiğiniz origin’in ana sayfasını ister (yollar ve sorgu dizeleri atılır), en fazla beş yönlendirmeyi izler ve son yanıtı değerlendirir. Başka sayfa istenmez.
• Çoğunlukla varlığa bakar. Eksik CSP, HTTPS hedefte eksik HSTS ve çerçeveleme korumasının olmaması orta olarak derecelendirilir. Access-Control-Allow-Origin: *, nosniff dışındaki X-Content-Type-Options, eksik Referrer-Policy, herhangi bir X-Powered-By başlığı ve sürüm numarası içeren bir Server başlığı düşük olarak derecelendirilir. Sürümsüz Server: nginx bilgi amaçlı gösterilir ve risk sinyali sayılmaz. O yanıtta HttpOnly olmadan ya da HTTPS’te Secure olmadan ayarlanan çerezler orta olarak derecelendirilir; SameSite kontrol edilmez.
• Ayrı bir sertleştirme notu (A–F), mevcut başlıkları TLS sonucuyla birlikte puanlar ve CSP 'unsafe-inline' (veya betikler için 'unsafe-eval') içeriyorsa ona daha az puan verir. Permissions-Policy ve COOP yalnızca bu notta sayılır.
• Snapshot’ın ayrı HTTPS yönlendirme kontrolü, girdiğiniz değere bağlıdır. Çıplak alan adı veya https:// adresi için 180 günün altındaki HSTS max-age değerini düşük olarak işaretler (kademeli artış sırasında beklenen bir durum) ve sayfa HTML’inde http:// referanslarını (karma içerik) arar; HTTP’den HTTPS’e yönlendirmeyi test etmez. Yönlendirme yalnızca http:// adresini girdiğinizde test edilir ve bu çalıştırma TLS kontrolünü atlar, eksik HSTS’yi raporlamaz.

Sonuç tek bir puan, sertleştirme notu, risk sinyali ve geçen kontrol sayıları, riskler önce olmak üzere en fazla üç sinyal ve derecelendirmeleriyle birlikte sekiz kontrolün tamamını gösterir. Kontrol ettiği sekiz başlık için derecelendirmeyi ve varsa gözlenen değeri gösterir; yanıtın gönderdiği her başlığı göstermez. Gerisi ve diğer sayfalar için DevTools veya curl kullanın.

Bu kontrolü ilk sırada açmak için ücretsiz güvenlik başlıkları kontrolünü kullanın: aynı snapshot’ı çalıştırır ve başlık kontrolünü açık hâlde diğer yedi kontrolün üstünde listeler.