HTTP yanıt başlıkları neyi anlatır?

Başlıkları terminalden çekmek: curl -I

Bir URL'nin yanıt başlıklarını görmenin en hızlı yolu "curl -I https://ornek.com" komutudur; bu, sunucudan sadece başlıkları ister (HEAD isteği) ve gövdeyi indirmez. Sunucu HEAD'i düzgün desteklemiyorsa "curl -sD - -o /dev/null https://ornek.com" daha güvenilir sonuç verir: gövdeyi indirip atarken başlıkları (-D -) ekrana yazdırır.

Çıktının ilk satırı durum satırıdır: "HTTP/2 200" gibi. Ardından her satır "Başlık-Adı: değer" biçiminde gelir. Yönlendirmeleri de takip etmek isterseniz "-L" bayrağını eklemeniz, her hop'ta ayrı bir başlık bloğu görmeniz için ise "-v" (verbose) modunu kullanmanız gerekir; tarayıcıda aynı bilgiyi geliştirici araçlarının Network sekmesinden de görebilirsiniz.

İsteği belirli bir istemciymiş gibi göndermek isterseniz "-A" bayrağıyla User-Agent değiştirebilirsiniz; örneğin "curl -A 'Googlebot/2.1' -I https://ornek.com" sunucunun arama motoru botlarına farklı başlıklar (ya da farklı bir yönlendirme) döndürüp döndürmediğini ortaya çıkarabilir. Bu, bir siteyi normal ziyaretçiye 200 döndürürken botlara farklı davranan cloaking benzeri yapılandırmaları tespit etmek için kullanışlı bir tekniktir.

Durum kodu ne anlatır?

Durum kodunun ilk rakamı kategoriyi belirler: 2xx başarı (200 OK, 204 No Content), 3xx yönlendirme (301 kalıcı, 302 geçici, 304 Not Modified — önbellekten kullan), 4xx istemci hatası (404 bulunamadı, 403 yasak, 429 çok fazla istek), 5xx sunucu hatası (500 iç hata, 503 hizmet dışı). Bir sayfanın gerçekte hangi kodu döndürdüğünü bilmeden, sadece tarayıcıda "açılıyor" görünümüne bakarak SEO veya entegrasyon sorunlarını teşhis etmek yanıltıcı olabilir; örneğin bir 404 sayfası tasarım olarak başarılı görünüp yine de 200 döndürebilir (soft 404).

301 ile 302 arasındaki fark özellikle arama motorları için önemlidir: 301 "kalıcı taşındı" der ve arama motoru sıralama değerini yeni adrese aktarır, 302 "geçici" anlamına gelir ve eski adres indekste kalmaya devam edebilir. Bir yönlendirme zincirinin her adımını görmek için Redirect Kontrol aracı her hop'un durum kodunu, hedefini ve süresini ayrı ayrı listeler.

307 ve 308 daha yeni kodlardır ve 302/301'den tek farkları isteğin gövdesini ve HTTP metodunu (POST gibi) değiştirmeden korumalarıdır; eski 301/302 bazı istemcilerde bir POST isteğini yönlendirme sırasında GET'e çevirebilir, 307/308 bunu garanti altına almaz. API'lerde veya form gönderimlerinde yönlendirme kullanılacaksa 307/308 tercih edilmesi bu yüzden daha güvenlidir.

Önbellekleme başlıkları

"Cache-Control" bir kaynağın ne kadar süreyle ve nasıl önbelleğe alınacağını belirler: "max-age=3600" bir saat boyunca yeniden sorulmadan kullanılabileceğini, "no-store" hiç önbelleğe alınmaması gerektiğini, "public"/"private" ise paylaşılan önbelleklerin (CDN, proxy) mi yoksa sadece tarayıcının mı saklayabileceğini söyler. "Expires" başlığı daha eski bir alternatiftir ve mutlak bir tarih verir; ikisi birlikte varsa Cache-Control önceliklidir.

"ETag" ve "Last-Modified" ise koşullu istekler için kullanılır: tarayıcı bir kaynağı tekrar isterken bu değerleri "If-None-Match" / "If-Modified-Since" olarak gönderir, içerik değişmemişse sunucu gövdeyi tekrar göndermek yerine sadece "304 Not Modified" döner — bu, bant genişliğinden tasarruf sağlayan küçük ama etkili bir mekanizmadır.

Statik dosyalarda (resim, CSS, JS gibi dosya adında bir hash/sürüm numarası taşıyanlarda) genelde çok uzun bir "max-age" ile agresif önbellekleme yapılır çünkü içerik değiştiğinde dosya adı da değişir, eski önbellek asla yanlış içerik sunmaz; HTML sayfalarında ise genelde daha kısa bir süre veya "no-cache" (önbelleğe al ama her seferinde sunucuya doğrula) tercih edilir. "no-cache" ile "no-store" sık karıştırılır: no-cache önbelleğe almayı yasaklamaz, sadece kullanmadan önce sunucuya doğrulama zorunluluğu getirir; no-store içeriğin hiçbir yerde saklanmamasını ister.

Sıkıştırma ve boyut

"Content-Encoding" başlığı yanıtın hangi algoritmayla sıkıştırıldığını gösterir; en yaygınları gzip ve daha yeni, genelde daha iyi oranlar veren brotli (br)'dır. Tarayıcı "Accept-Encoding" başlığıyla hangi sıkıştırmaları desteklediğini bildirir, sunucu bunlardan birini seçip yanıtı ona göre kodlar. Bir metin tabanlı yanıtta (HTML, CSS, JS, JSON) sıkıştırmanın kapalı olması, gereksiz yere büyük transferlere ve yavaş yüklenmeye yol açar.

"Content-Length" sıkıştırılmış gövdenin bayt cinsinden boyutunu verir; "Transfer-Encoding: chunked" kullanılan yanıtlarda ise toplam boyut önceden bilinmediği için bu başlık bulunmaz, veri parçalar (chunk) hâlinde akar. "Server" başlığı sunucu yazılımını (nginx, Apache, belirli bir sürüm) ifşa edebilir; bu bilgi saldırganlara hedefli açık arama kolaylığı sağlayabileceğinden birçok ekip bu başlığı bilinçli olarak gizler veya jenerikleştirir.

Güvenlik başlıkları

"Strict-Transport-Security" (HSTS, RFC 6797) tarayıcıya bu alan adına bir daha asla düz HTTP ile bağlanmamasını, her zaman HTTPS'e otomatik geçmesini söyler; "max-age" saniye cinsinden süreyi, "includeSubDomains" kuralın alt alan adlarını da kapsadığını belirtir. Bu başlık eksikse, kullanıcı bir kere http:// ile bağlanmaya çalıştığında araya giren biri (aynı ağda) bağlantıyı düşürüp trafiği dinleyebilir.

"Content-Security-Policy" (CSP) hangi kaynaktan script, stil, resim, font yüklenebileceğini beyaz listeye alarak XSS (siteler arası betik çalıştırma) saldırılarını büyük ölçüde azaltır; "X-Content-Type-Options: nosniff" tarayıcının bir dosyanın MIME tipini tahmin etmeye çalışmasını (ve bunun güvenlik açığına dönüşmesini) engeller; "X-Frame-Options" veya CSP'nin "frame-ancestors" yönergesi sayfanın başka bir sitede iframe içine gömülmesini (clickjacking saldırılarını) engeller; "Referrer-Policy" bir bağlantı tıklandığında hedef siteye hangi bilginin Referer olarak gönderileceğini sınırlar; "Permissions-Policy" ise kamera, mikrofon, konum gibi tarayıcı özelliklerine hangi kaynakların erişebileceğini kısıtlar.

• Strict-Transport-Security — HTTPS'e zorunlu geçiş
• Content-Security-Policy — kaynak beyaz listesi, XSS azaltma
• X-Content-Type-Options: nosniff — MIME tahmin saldırılarını engelleme
• X-Frame-Options / frame-ancestors — iframe'e gömülmeyi engelleme (clickjacking)
• Referrer-Policy — hedef siteye giden Referer bilgisini sınırlama
• Permissions-Policy — kamera/mikrofon/konum gibi tarayıcı izinlerini kısıtlama

Set-Cookie ve gizlilik

"Set-Cookie" başlığı bir tanımlama bilgisini tarayıcıya kaydettirir ve "Secure" (yalnızca HTTPS üzerinden gönder), "HttpOnly" (JavaScript'ten erişilemez, XSS'e karşı korur), "SameSite" (Strict/Lax/None — üçüncü taraf isteklerde çerezin gönderilip gönderilmeyeceği) gibi bayraklar taşır. Bu bayraklardan biri eksikse çerez, olması gerekenden daha geniş bir saldırı yüzeyine açık kalabilir.

Çerez değerlerinin kendisi genelde oturum kimlikleri gibi hassas veriler taşıdığından, HTTP Header Kontrol aracı Set-Cookie değerlerini raporda maskeler; sadece bayrakların (Secure, HttpOnly, SameSite) var olup olmadığını gösterir, çerezin gerçek içeriğini ifşa etmez.

"SameSite=None" kullanılan bir çerez -örneğin üçüncü taraf bir gömülü widget'ın oturum çerezi- tarayıcı kurallarına göre mutlaka "Secure" bayrağıyla birlikte gönderilmelidir, aksi hâlde modern tarayıcılar bu çerezi tamamen reddeder. "SameSite=Strict" ise en katı seçenektir ve çerezin yalnızca sitenin kendi sayfalarından gelen isteklerde gönderilmesini sağlar; bu, CSRF (siteler arası istek sahteciliği) saldırılarına karşı ek bir koruma katmanı oluşturur ama bazı meşru senaryolarda (bir bağlantıdan gelen oturum açık kullanıcı) beklenmedik davranışlara da yol açabilir.

Hızlı bir kontrol listesi

Bir siteyi header açısından değerlendirirken önce durum kodunun beklediğiniz gibi olduğunu (200 ya da doğru bir yönlendirme kodu), ardından HTTPS'in HSTS ile zorunlu kılındığını, statik içeriklerde makul bir Cache-Control süresinin ayarlandığını, metin yanıtlarında sıkıştırmanın açık olduğunu ve en azından X-Content-Type-Options ile X-Frame-Options'ın (veya CSP'nin frame-ancestors yönergesinin) bulunduğunu kontrol etmek iyi bir başlangıç noktasıdır.

URL'de Türkçe karakter veya kodlanmış sorgu parametreleri varsa isteği göndermeden önce URL Decode ile parametrelerin gerçekte neyi ifade ettiğini çözmek, hangi sayfaya gerçekten istek attığınızı netleştirir; sertifika ile ilgili bir şüpheniz varsa SSL Kontrol ile zincir ve geçerlilik tarihini ayrı olarak doğrulamak, header raporundaki HTTPS bulgularını tamamlar. Bu kontrolleri bir kerelik değil, özellikle sunucu veya CDN yapılandırması değiştikten sonra tekrar tekrar çalıştırmak, bir güvenlik başlığının fark edilmeden kaybolmasının önüne geçer.