HTTP Güvenlik Başlıkları: Web Siteleri İçin Uygulama ve Test Rehberi

Son Güncelleme: Eylül 2026

HTTP güvenlik başlıkları, web sunucusunun tarayıcıya içerikleri nasıl işleyeceğini bildiren yanıtlardır. Doğru yapılandırılmış Content Security Policy (içerik güvenliği politikası), HSTS (HTTP katı taşıma güvenliği) ve diğer başlıklar; güvenli bağlantı kullanımını güçlendirmeye, gereksiz tarayıcı yeteneklerini sınırlamaya ve bazı istemci tarafı saldırılarının etkisini azaltmaya yardımcı olur. Ancak etkili bir kurulum, bütün başlıkları rastgele eklemekten değil, uygulamanın ihtiyaçlarını belirleyip değişiklikleri test etmekten geçer.

İçindekiler

• HTTP Güvenlik Başlıkları Nedir?
• Temel Güvenlik Başlıkları ve Görevleri
• CSP Politikası Nasıl Planlanır?
• HSTS'ye Güvenli Geçiş
• Sunucuda Örnek Yapılandırma
• Test ve Sorun Giderme
• Uygulama Senaryoları
• Sıkça Sorulan Sorular
• Sonuç

HTTP Güvenlik Başlıkları Nedir?

Bir tarayıcı web sayfasını istediğinde sunucu, içerikle birlikte HTTP yanıt başlıkları gönderir. Güvenlik başlıkları; hangi kaynakların yüklenebileceği, sayfanın başka bir sitede çerçeve içine alınıp alınamayacağı veya sonraki ziyaretlerde bağlantının yalnızca HTTPS üzerinden kurulup kurulmayacağı gibi davranışları tanımlar. Genellikle uygulama, web sunucusu veya ters vekil (reverse proxy) katmanında ayarlanırlar.

Başlıkların görevi, uygulamanın güvenlik açıklarını tek başına ortadan kaldırmak değildir. Örneğin CSP, kötü niyetli bir betiğin çalışmasını bazı durumlarda engelleyebilir; fakat kullanıcı girdilerinin güvenli işlenmesi, erişim denetimi ve yazılım güncellemeleri yine gereklidir. Benzer şekilde HSTS, tarayıcının HTTPS kullanımını zorunlu tutmasına yardımcı olur ama sunucuda geçerli bir sertifika bulunmasının yerini almaz. Bu nedenle başlıkları katmanlı güvenliğin bir parçası olarak değerlendirmek gerekir.

Ayrıca her başlık her kaynak için uygun olmayabilir. Bir yönetim paneli başka sitelerde gömülmemeliyken iş ortakları için hazırlanan bir gösterge panelinin kontrollü biçimde gömülmesi gerekebilir. Güvenlik politikası, önce bu iş gereksinimlerini anlamalı; ardından izin verilen davranışları mümkün olduğunca dar tanımlamalıdır.

Temel Güvenlik Başlıkları ve Görevleri

Aşağıdaki tablo, sık kullanılan başlıkların neyi kontrol ettiğini ve dağıtıma geçmeden önce hangi sorunun sorulması gerektiğini özetler. Örnek değerler her uygulamaya olduğu gibi kopyalanacak evrensel ayarlar değildir.

İçerik türü ve yönlendiren bilgisi

X-Content-Type-Options: nosniff, tarayıcının bazı kaynaklarda sunucunun bildirdiği içerik türü yerine kendi tahminine dayanmasını önlemeye yardımcı olur. Bu başlığı eklerken JavaScript ve CSS gibi dosyaların doğru Content-Type değeriyle sunulduğunu da doğrulayın; yanlış içerik türünü düzeltmek yerine başlığı kaldırmak kalıcı çözüm değildir. Referrer-Policy: strict-origin-when-cross-origin ise farklı sitelere yapılan uygun isteklerde ayrıntılı sayfa adresi yerine daha sınırlı yönlendiren bilgisi paylaşılmasını sağlar.

Tarayıcı özellikleri ve çerçeveleme

Permissions-Policy ile ihtiyaç duyulmayan konum, kamera ve mikrofon gibi özellikler kısıtlanabilir. Örneğin yalnızca blog yazıları yayımlayan bir sitede bu özellikleri kapatmak makul olabilir; tarayıcı üzerinden görüntülü görüşme sunan bir uygulamada aynı politika işlev kaybına yol açar. Çerçeveleme için CSP içindeki frame-ancestors yönergesi kullanılabilir. Bu yönerge, sayfanın hangi üst sayfalar tarafından gömülebileceğini belirler; sayfanın kendi içinde hangi çerçeveleri açabileceğini belirleyen frame-src ile karıştırılmamalıdır.

Önemli ayrım: CORS (kökenler arası kaynak paylaşımı), başka kökenlerdeki betiklerin belirli yanıtlara erişimini düzenler; CSP ise sayfanın hangi kaynakları yükleyebileceğini ve başka davranışlarını denetler. Bir CSP sorunu, bütün kökenlere erişim izni veren CORS başlıkları eklenerek çözülmemelidir. Özellikle kimlik bilgisi taşıyan isteklerde genel izin kullanmak, beklenen erişim modeline de uymaz.

CSP Politikası Nasıl Planlanır?

CSP, güvenlik başlıkları arasında en fazla uygulama bilgisi gerektirenlerden biridir. Sayfanın kendi alan adından gelen kaynakları tanımlayan 'self' ifadesi başlangıç için yararlı olabilir; ancak harici ödeme bileşenleri, yazı tipleri, analitik araçları veya içerik dağıtım ağları kullanılıyorsa tek başına yeterli olmayabilir. Buna karşılık her kaynağa geniş izin vermek de politikanın değerini azaltır. Önce gerçek bağımlılıkları çıkarıp sonra gerekli kökenleri ayrı ayrı değerlendirin.

Önce envanter, sonra politika

• Betikler: Uygulama kodunun nereden geldiğini, sayfa içi betik bulunup bulunmadığını ve üçüncü taraf bileşenleri belirleyin.
• Stiller: Tema dosyaları, harici stil hizmetleri ve sayfa içi stiller için mevcut kullanımı inceleyin.
• Görseller: Kullanıcı yüklemeleri ve harici görsel hizmetleri dahil gerçek kaynakları listeleyin.
• Bağlantılar: Uygulamanın API, ödeme ve kimlik doğrulama uç noktalarını değerlendirin.
• Gömülü içerik: Harici videoları, başka sitelerde gösterilen sayfaları ve yönetim paneli gereksinimlerini ayrı ayrı ele alın.

İlk aşamada Content-Security-Policy-Report-Only kullanmak, politika ihlallerini gözlemlemeye olanak tanır; bu mod ihlalleri engellemez. Raporları inceleyip meşru kaynakları belirledikten sonra politikayı uygulayan Content-Security-Policy başlığına geçebilirsiniz. Gözlemlenen her ihlali otomatik olarak izin listesine eklemeyin: tarayıcı eklentileri, beklenmedik üçüncü taraf kodları veya gerçekten engellenmesi gereken yüklemeler de rapor oluşturabilir.

Aşağıdaki politika, yalnızca kendi kökeninden kaynak yükleyen ve başka sitelerde gömülmesi gerekmeyen basit bir uygulama için inceleme örneğidir. Sayfa içi betik veya stil kullanan uygulamalarda doğrudan etkinleştirilmesi işlevleri bozabilir:

Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

default-src genel bir başlangıç kuralıdır; bazı yönergeler için geri dönüş kuralı değildir. Özellikle frame-ancestors belirtilmezse default-src 'none' değeri sayfanın başka sitelerde gömülmesini tek başına engellemez. Gömülmeyi önlemek istiyorsanız frame-ancestors 'none' yönergesini açıkça yazın. Sayfa içi betikleri desteklemek gerektiğinde geniş izinler vermek yerine uygulamaya uygun nonce (tek kullanımlık değer) veya hash (özet değer) yaklaşımını ayrıca değerlendirin.

HSTS'ye Güvenli Geçiş

HSTS, tarayıcıya belirli bir alan adına sonraki ziyaretlerinde HTTPS kullanmasını söyler. Başlık, HTTPS yanıtında alınmalıdır; HTTP üzerinden gönderilmesi güvenilir bir etkinleştirme yöntemi değildir. Bu nedenle önce geçerli SSL/TLS sertifikasını, HTTPS erişimini ve HTTP'den HTTPS'ye yönlendirmeyi hazırlayın. İlk ziyarette tarayıcı henüz bu alan adı için HSTS politikası bilmiyor olabilir; HSTS'yi mevcut bağlantı güvenliğinin alternatifi olarak görmeyin.

max-age, politikanın tarayıcı tarafından kaç saniye hatırlanacağını belirtir. Kapsamı genişletmeden önce kısa bir süreyle uygulamayı sınamak, yanlış yapılandırma riskini azaltır. includeSubDomains eklendiğinde alt alan adları da kapsam içine girer. Örneğin eski bir iç uygulama yalnızca HTTP destekliyorsa üst alan adına bu yönergeyi eklemek kullanıcıların erişimini bozabilir. Her alt alan adının HTTPS hazırlığını, sertifika kapsamını ve yenileme sürecini ayrı ayrı kontrol edin.

preload seçeneğini ise sıradan bir performans ayarı gibi kullanmayın. Ön yükleme, tarayıcıların alan adını önceden HTTPS zorunlu olarak tanımasını hedefler ve uzun süreli operasyonel taahhüt gerektirir. Geçişi geri almak yalnızca sunucu başlığını silmek kadar hızlı olmayabilir. Mevcut HSTS politikasını devre dışı bırakmak için HTTPS yanıtında max-age=0 gönderilebilir; ancak önceden dağıtılmış ön yükleme kayıtları ayrı bir değerlendirme gerektirir.

Sunucuda Örnek Yapılandırma

Güvenlik başlıkları uygulama kodunda, web sunucusunda veya içerik dağıtım katmanında tanımlanabilir. Tek bir sorumlu katman seçmek, aynı başlığın farklı değerlerle birden fazla kez gönderilmesini önlemeye yardımcı olur. Aşağıdaki Nginx örneği yalnızca HTTPS sunucu bloğu içinde, gereksinimleri doğrulanmış bir uygulama için başlangıç noktasıdır. Sunucunuzdaki mevcut konum blokları ve ters vekil ayarlarıyla birlikte değerlendirilmelidir:

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

Burada CSP yalnızca raporlama modundadır; politikayı uygulamaz. HSTS için kullanılan kısa süre de ilk doğrulama aşamasına yöneliktir. Nginx yapılandırmalarında başlıkların kapsamı, alt konum bloklarındaki başlık ayarlarından etkilenebilir. Bu yüzden yapılandırma dosyasının doğru görünmesi yeterli değildir; gerçek yanıtları her önemli URL üzerinden denetleyin.

Değişiklik öncesinde mevcut yapılandırmayı yedekleyin. Ardından sözdizimi kontrolünü yapıp yalnızca başarılıysa hizmeti yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx

Apache HTTP Server kullanan ortamlarda karşılık gelen ayarlar, etkin modüllere ve sanal ana makine (virtual host) yapısına göre değişir. Örneğin mod_headers etkinse aşağıdaki satırlar, uygun HTTPS sanal ana makinesinde değerlendirilebilir:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
Header always set Strict-Transport-Security "max-age=300"

Paylaşımlı hosting ortamında web sunucusunun bütün yapılandırmasına erişiminiz olmayabilir. Bu durumda kullanılabilen panel ayarlarını veya uygulama katmanını inceleyin; mevcut başlıkların üzerine yazılıp yazılmadığını hizmet sağlayıcınızla netleştirin. Önceden eklenmiş bir HSTS politikasını fark etmeden değiştirmek de risklidir.

Test ve Sorun Giderme

Başlıkları yalnızca ana sayfada görmek yeterli değildir. Giriş sayfası, yönetim paneli, hata sayfası ve farklı uygulama yollarında farklı yanıtlar üretilebilir. Tarayıcı geliştirici araçlarındaki ağ (network) bölümünü ve terminalde yanıt başlıklarını birlikte inceleyin. Örneğin kendi alan adınızın gerçek adresini kullanarak şu sorguyu yapabilirsiniz:

curl -I https://ornek-alan-adiniz.test/

curl -I bir HEAD isteği gönderir. Bazı uygulamalar HEAD ve GET isteklerine farklı davranabileceğinden, şüpheli durumlarda GET yanıtının başlıklarını da denetleyin:

curl -sS -D - -o /dev/null https://ornek-alan-adiniz.test/

• Başlık görünmüyor: Yanıtı gerçekten hangi katmanın ürettiğini, HTTPS sanal ana makinesini ve farklı konum kurallarını kontrol edin.
• CSP sonrası kaynak yüklenmiyor: Tarayıcı konsolundaki engellenen kaynak bilgisini inceleyin; izin vermeden önce kaynağın gerekli ve güvenilir olduğunu doğrulayın.
• Alt alan adı açılmıyor: HSTS kapsamını, sertifikayı, HTTPS dinleyicisini ve ilgili alt alan adının yönlendirmelerini denetleyin.
• Sayfa gömülemiyor: Hem frame-ancestors politikasını hem de varsa X-Frame-Options değerini inceleyin.
• Beklenmeyen farklı sonuçlar: Önbellek, içerik dağıtım katmanı ve uygulama sunucusunun aynı başlığı farklı biçimde üretip üretmediğini karşılaştırın.

İyi bir dağıtım planında önce test ortamı, sonra sınırlı canlı yayın ve son olarak genel yayın bulunur. Değişiklikten önce temel kullanıcı akışlarını kaydedin: oturum açma, ödeme, dosya yükleme ve yönetim paneli işlemleri bunlara örnektir. Başlık güncellemesinden sonra aynı akışları yeniden çalıştırmak, yalnızca teknik başlığın varlığını değil gerçek kullanıcı deneyimini de doğrular.

Uygulama Senaryoları

Kurumsal tanıtım sitesi

Harici betik kullanmayan basit bir tanıtım sitesinde CSP'yi dar tutmak görece kolaydır. Siteyi başka alan adlarında gömme gereksinimi yoksa frame-ancestors 'none' düşünülebilir. Buna rağmen iletişim formunun doğrulama bileşenini, harici yazı tiplerini ve ölçüm araçlarını test etmeden politika uygulamayın. HTTPS bütün alt alan adlarında hazır değilse HSTS kapsamını aceleyle genişletmeyin.

E-ticaret ve ödeme akışı

Ödeme sağlayıcısının yönlendirmeleri, açılır pencereleri veya gömülü bileşenleri olabilir. Bu senaryoda güvenlik başlıklarını sıkılaştırmak kadar ödeme adımlarının kesintisiz çalıştığını doğrulamak da önemlidir. CSP raporlama modunda gerçek ödeme akışını gözlemlemek, gereksiz geniş kaynak izinleri eklemeden doğru istisnaları belirlemeye yardımcı olur. Testleri yalnızca ürün sayfasında değil, sepet ve ödeme dönüş sayfalarında da yürütün.

Yönetim paneli ve API

Yönetim paneli, genel siteden daha katı çerçeveleme kurallarına ihtiyaç duyabilir. API yanıtlarının ise HTML sayfalarından farklı içerik türü ve CORS gereksinimleri vardır. Tek bir küresel politika her iki bileşene uymazsa ilgili yollar veya sanal ana makineler için ayrı politikalar tasarlayın. Yetkilendirme denetimini tarayıcı başlıklarına bırakmayın; API her isteğin erişim hakkını sunucu tarafında doğrulamalıdır.

Sıkça Sorulan Sorular

Sonuç

HTTP güvenlik başlıkları, web uygulamasının tarayıcıyla kurduğu güvenlik sözleşmesini daha açık hâle getirir. Başarılı bir uygulama için önce kaynak envanterini çıkarın, uygun başlıkları seçin, CSP'yi gözlemleyerek geliştirin ve HSTS kapsamını HTTPS hazırlığıyla birlikte genişletin. Yapılandırmayı yalnızca dosyada değil, canlı yanıtlar ve gerçek kullanıcı işlemleri üzerinde doğrulayın.

Güvenlik başlıklarını yöneteceğiniz altyapıyı planlarken Corelux Hosting ve Sanal Sunucu seçeneklerini inceleyebilirsiniz. HTTPS altyapısı için SSL Sertifikası, olası yapılandırma hatalarına karşı veri koruma planı için Yedekleme Hizmeti sayfaları da değerlendirmeye değerdir.