HTTP Güvenlik Başlıkları Rehberi: HSTS, CSP, X‑Frame‑Options ve Referrer‑Policy Doğru Nasıl Kurulur?

Güvenlik denetimlerinde en sık gördüğümüz sorunlardan biri, sunucu tarafı yamaların güncel olmasına rağmen HTTP güvenlik başlıklarının ya hiç tanımlanmamış ya da eksik/yanlış ayarlanmış olması. Uygulama kodu tarafında XSS, CSRF, SQL injection açıklarını kapatmak elbette kritik; ancak tarayıcıya doğru talimatları vermediğiniz sürece, güçlü bir savunma hattı kurmuş sayılmazsınız. Özellikle HSTS, CSP, X‑Frame‑Options ve Referrer‑Policy gibi başlıklar, hem saldırı yüzeyini daraltır hem de KVKK / GDPR gibi regülasyonlara uyumda önemli rol oynar.

Bu rehberi, DCHost altyapısında barındırılan web sitelerinde yaptığımız güvenlik sertleştirme çalışmalarındaki gerçek tecrübelerimize dayanarak hazırladık. Amaç; teorik tanımlardan çok, bu başlıkları Nginx/Apache üzerinde pratik olarak nasıl ayarlamanız gerektiğini, hangi sırayla devreye almanızın daha güvenli olduğunu ve yayına almadan önce hangi kontrolleri yapmanız gerektiğini netleştirmek. Özellikle canlı e‑ticaret, SaaS veya kurumsal sitelerde, tek satırlık hatalı bir HSTS veya CSP politikası beklenmedik kesintilere yol açabilir. Gelin bu riskleri en baştan bertaraf edecek, adım adım ilerleyen bir yaklaşım kuralım.

HTTP Güvenlik Başlıklarının Rolü ve Tehdit Modeli

Önce bu başlıkların neyi çözdüğünü netleştirmek önemli. Çoğu zaman geliştiriciler, güvenlik başlıklarını bir “puan yükseltme” adımı gibi görüyor; oysa bunlar doğrudan saldırı senaryolarına karşı çalışıyor:

• HSTS (Strict-Transport-Security): HTTP’den HTTPS’e protokol düşürme (downgrade) saldırılarını ve kullanıcıların yanlışlıkla şifreli olmayan bağlantı kurmasını engeller.
• CSP (Content-Security-Policy): XSS, veri sızdırma ve zararlı üçüncü parti içeriklerin yüklenmesini ciddi şekilde zorlaştırır.
• X-Frame-Options: Clickjacking saldırılarını (sitenizin başka bir sitede iframe içinde gizlenmesi) engeller.
• Referrer-Policy: Ziyaretçi URL’lerinizin başka sitelere ne kadar detayla gönderileceğini kontrol ederek gizliliği ve veri sızıntısı riskini yönetir.

Bu başlıkları doğru kullanmak, özellikle KVKK ve GDPR uyumlu hosting stratejilerinde, “en az ayrıcalık” (least privilege) prensibini tarayıcı tarafına da taşımak anlamına gelir. Yani tarayıcıya “yalnızca gerçekten ihtiyaç duyduğun kaynaklara, gerçekten ihtiyaç duyduğun şartlarda eriş” demiş olursunuz.

Başlamadan Önce: HTTPS, SSL/TLS ve Test Ortamı Zorunluluğu

Bu rehberdeki başlıkların çoğu, HTTPS olmadan ya çalışmaz ya da anlamını kaybeder. Özellikle HSTS, sadece HTTPS üzerinden gelen yanıtlar için anlamlıdır. Bu nedenle ilk adımınız her zaman:

• Geçerli bir SSL/TLS sertifikası kurmak,
• Tüm HTTP trafiğini kalıcı 301 ile HTTPS’e yönlendirmek,
• Eski, zayıf protokolleri (SSLv3, TLS 1.0, TLS 1.1) kapatmak olmalı.

Bu konularda adım adım ilerlemek için HTTP’den HTTPS’e geçiş rehberi ve TLS 1.3 ve modern SSL/TLS yapılandırması hakkındaki rehberlerimize mutlaka göz atın.

İkinci kritik önkoşul ise test/staging ortamı. CSP ve HSTS gibi başlıklar hataya çok az tolerans tanır. Bu yüzden DCHost müşterilerimize her zaman şu sırayı öneriyoruz:

1. Önce staging ortamında başlıkları devreye alın.
2. Tarayıcı konsolu ve loglar üzerinden hataları toplayın.
3. Gerekirse CSP’yi bir süre Report-Only modunda çalıştırın.
4. Ancak her şey temizken canlıya geçin.

HSTS (Strict-Transport-Security) Doğru Nasıl Ayarlanır?

HSTS, tarayıcıya “bu alan adına her zaman HTTPS üzerinden bağlan” diyen bir talimattır. Böylece kullanıcı adres çubuğuna http:// yazsa bile tarayıcı kendisi otomatik olarak HTTPS’e yükseltir. Bu, özellikle kamu Wi‑Fi ağlarında yapılan protokol düşürme ve SSL strip saldırılarını etkisiz hale getirir.

HSTS Direktifleri

• max-age: Tarayıcının bu kuralı kaç saniye boyunca hatırlayacağını belirtir. Örneğin 31536000, yaklaşık 1 yıl demektir.
• includeSubDomains: Tüm alt alan adlarına da aynı zorlamayı uygular (www, api, panel vb.).
• preload: Sitenizi tarayıcıların HSTS preload listesine eklemek için kullanılır. Bu listeye girdikten sonra, kullanıcı sitenize ilk kez girerken bile direkt HTTPS kullanılır.

HSTS Ayarını Aşamalı Yapmak Neden Önemli?

HSTS’nin en tehlikeli yanı, yanlış yapılandırmanın geri dönüşü çok zor hatalara yol açabilmesi. Örneğin henüz HTTPS’i düzgün çalışmayan bir alt alan adında includeSubDomains kullanırsanız, o alt alan adına erişmeye çalışan tüm kullanıcılarınız için siteyi fiilen kapatmış olursunuz.

Bu yüzden DCHost’ta izlediğimiz tipik yol haritası şöyle:

1. Önce sadece ana alan adı için, kısa bir süreli (max-age=300 gibi) HSTS başlığı gönderin.
2. Logları ve kullanıcı geri bildirimlerini takip edin; herhangi bir sorun yoksa süreyi kademeli olarak uzatın (ör. 1 gün, 1 hafta, 1 ay, 1 yıl).
3. Tüm alt alan adlarınızın HTTPS yapılandırmasından emin olduktan sonra includeSubDomains ekleyin.
4. En son aşamada HSTS preload listesine başvurmayı değerlendirin.

Nginx Üzerinde HSTS Örneği

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # HSTS: ilk aşamada kısa bir süre deneyebilirsiniz
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    ... diğer ayarlar ...
}

always parametresi, hata yanıtlarında (ör. 500, 404) bile bu başlığın gönderilmesini sağlar. Böylece kullanıcı sitenizde hata sayfası görse dahi, tarayıcısında HSTS kaydı güncel kalır.

Apache Üzerinde HSTS Örneği

<VirtualHost *:443>
    ServerName example.com

    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

    ... diğer ayarlar ...
</VirtualHost>

Not: Apache’de bu başlığı kullanmadan önce mod_headers modülünün etkin olduğundan emin olun.

CSP (Content-Security-Policy): XSS’e Karşı En Güçlü Kalkan

CSP, tarayıcıya hangi kaynaktan hangi tür içeriğin yüklenebileceğini söyleyen bir beyaz liste mekanizmasıdır. Örneğin:

• JavaScript sadece kendi domain’inden ve belirli CDN’lerden yüklensin,
• Inline script’lere izin verilmesin, sadece nonce veya hash’li script’ler çalışabilsin,
• Form gönderimleri sadece belirli alan adlarına yapılsın,
• Iframe içine sadece belirli siteler gömülebilsin gibi.

CSP başlığı karmaşık görünebilir; ancak doğru stratejiyle adım adım sade bir politika kurmak mümkün. Bu konuyu detaylı ele aldığımız CSP’yi doğru kurmak rehberini de mutlaka okumanızı öneririz.

CSP Temel Direktifleri

• default-src: Diğer tüm içerik türleri için varsayılan politika.
• script-src: JavaScript dosyaları için kaynak listesi.
• style-src: CSS dosyaları ve inline stiller.
• img-src: Görsellerin yüklenebileceği kaynaklar.
• connect-src: XHR, fetch, WebSocket gibi bağlantıların hedefleri.
• frame-ancestors: Sitenizi iframe içine alabilecek üst siteleri tanımlar (X-Frame-Options yerine modern yol).

CSP’yi Report-Only ile Başlatmak

Canlı bir sitede, özellikle WordPress, WooCommerce veya karmaşık JavaScript SPA’larda, CSP’yi bir anda katı şekilde devreye almak genellikle fonksiyonellik bozulmalarına yol açar. Bu yüzden en iyi yöntem:

1. Önce Content-Security-Policy-Report-Only başlığı ile başlamak,
2. Tarayıcı konsolundaki CSP ihlallerini ve raporlarını toplamak,
3. Politikayı birkaç iterasyonda düzeltip sadeleştirdikten sonra,
4. Asıl Content-Security-Policy başlığını devreye almaktır.

Basit Bir CSP Örneği

Content-Security-Policy: 
  default-src 'self'; 
  script-src 'self' https://cdn.example.com; 
  style-src 'self' 'unsafe-inline'; 
  img-src 'self' data: https://images.example.com; 
  connect-src 'self' https://api.example.com; 
  frame-ancestors 'self';

Bu örnekte:

• Tüm içerikler varsayılan olarak sadece kendi alan adınızdan yüklenebilir.
• JavaScript için ek olarak bir CDN’e izin veriliyor.
• CSS için geçici olarak 'unsafe-inline' kullanılmış (zamanla nonceler/hash’lerle kaldırılmalı).
• Görseller, kendi alan adınız ve bir görsel CDN’inden yüklenebiliyor.
• XHR/fetch istekleri sadece API sunucunuza gidebiliyor.
• Siteniz sadece kendi içinde iframe olarak kullanılabiliyor.

Nginx’te CSP Başlığı

add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; connect-src 'self' https://api.example.com; frame-ancestors 'self'" always;

Satır uzunluğunu kısaltmak için Nginx’te değişken veya map yapılarıyla CSP’yi parçalara bölmek mantıklı olabilir; büyük kurumsal yapılarda bunu sıkça tercih ediyoruz.

Apache’de CSP Başlığı

Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; connect-src 'self' https://api.example.com; frame-ancestors 'self'"

CSP’nin özellikle çerez ve oturum güvenliğiyle bir arada ele alınması önemli. Örneğin, SameSite, Secure ve HttpOnly çerez ayarlarını doğru yapılandırıp CSP ile birlikte düşünmek, oturum çalma (session hijacking) riskini ciddi ölçüde azaltır.

X-Frame-Options: Clickjacking’e Karşı İlk Savunma Hattı

X-Frame-Options, sitenizin başka bir sitede iframe olarak gömülüp gömülemeyeceğini kontrol eder. Clickjacking saldırılarında, saldırgan sizin sitenizi şeffaf bir iframe içinde yükler, üstüne kendi butonlarını koyar ve kullanıcıyı farkında olmadan sizin siteniz üzerinde işlem yapmaya zorlar.

X-Frame-Options Değerleri

• DENY: Siteniz hiçbir şekilde iframe içine gömülemez.
• SAMEORIGIN: Siteniz sadece kendi alan adınız altında iframe içinde yüklenebilir.
• ALLOW-FROM uri: Artık modern tarayıcılarda büyük ölçüde desteklenmiyor, kullanılmaması önerilir.

Modern yaklaşımda, X-Frame-Options yanında veya onun yerine CSP’nin frame-ancestors direktifini kullanmak daha esnek ve standartlara uygun bir yöntemdir. Ancak geriye dönük uyumluluk için çoğu projede her ikisini birden görüyoruz.

Nginx’te X-Frame-Options

add_header X-Frame-Options "SAMEORIGIN" always;

Eğer sitenizin hiçbir yerde iframe içinde kullanılmasına gerek yoksa, DENY daha katı ve güvenli bir seçimdir:

add_header X-Frame-Options "DENY" always;

Apache’de X-Frame-Options

Header always set X-Frame-Options "SAMEORIGIN"

Unutmamanız gereken nokta: CSP’de frame-ancestors 'none' gibi bir kuralınız varsa ve X-Frame-Options’ta SAMEORIGIN derseniz, tarayıcı katı olan kuralı uygular. Bu nedenle çakışmayan, tutarlı kurallar yazmak önemli.

Referrer-Policy: Gizlilik, Analitik ve Güvenlik Dengesi

Her HTTP isteğinde tarayıcı, isteğin nereden geldiğini gösteren bir Referer (evet, tarihi yazım hatası) başlığı gönderir. Referrer-Policy, bu bilginin ne kadar detayla gönderileceğini belirler. Örneğin, tam URL’yi mi, sadece origin’i mi yoksa hiç mi göndermeyeceksiniz?

Yaygın Referrer-Policy Değerleri

• no-referrer: Hiç referrer gönderilmez. Maksimum gizlilik, ama analitik araçlar daha az veri görür.
• no-referrer-when-downgrade: Eski varsayılan davranış; HTTPS’ten HTTP’ye giderken referrer gönderilmez.
• origin: Sadece protokol + domain + port bilgisi gönderilir, tam yol değil.
• strict-origin-when-cross-origin: Kendi sitenizde tam referrer, dış sitelere giderken sadece origin ve HTTPS’ten HTTP’ye geçerken hiç referrer yok. Modern projeler için en dengeli seçeneklerden biri.

Bizim pratikte en çok önerdiğimiz değer, çoğu kurumsal ve e‑ticaret sitesinde strict-origin-when-cross-origin. Hem gizlilik açısından makul seviyede koruma sağlar hem de analitik/performans araçlarının temel ihtiyaçlarını karşılar.

Nginx’te Referrer-Policy

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache’de Referrer-Policy

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Eğer çok hassas içerik sunuyor (örneğin gizli panel URL’leri, özel müşteri portalları) ve dış bağlantılarda referrer’in kesinlikle görünmesini istemiyorsanız, no-referrer veya origin gibi daha katı seçenekleri de değerlendirebilirsiniz.

Tüm Başlıkları Bir Arada: Örnek Güvenlik Konfigürasyonu

Teoride her başlığı ayrı ayrı anlamak önemli, ama gerçek hayatta bunların hepsi aynı sunucu konfigürasyonunda bir araya geliyor. Tipik bir Nginx vhost’unda aşağıdaki gibi bir paket ayar kullanabilirsiniz:

Nginx İçin Örnek Güvenlik Başlıkları Bloğu

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # Zorunlu HTTPS
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # XSS, veri sızdırma ve içerik yükleme kontrolleri için CSP
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com; connect-src 'self' https://api.example.com; frame-ancestors 'self'" always;

    # Clickjacking koruması
    add_header X-Frame-Options "SAMEORIGIN" always;

    # Referrer gizliliği ve analitik dengesi
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Önerilen başka başlıklar da eklenebilir (X-Content-Type-Options, X-XSS-Protection vb.)

    ... diğer SSL / site ayarları ...
}

Benzer bir bloğu Apache tarafında da <VirtualHost *:443> içinde Header always set ... direktifleriyle kurabilirsiniz. Daha geniş perspektiften bakmak isterseniz, bu yazının kardeşi sayılabilecek genel HTTP güvenlik başlıkları rehberimize de mutlaka göz atın.

Canlıya Almadan Önce Kontrol Listesi

HSTS, CSP, X‑Frame‑Options ve Referrer‑Policy devreye alınırken en sık yapılan hatalar, doğrudan canlı ortamda denenmesi ve geri dönüş planının olmaması. DCHost tarafında, müşterilerimizin sitelerini sertleştirirken aşağıdaki kontrol listesini uyguluyoruz:

1. Yedek ve Geri Dönüş Planı

• Önce mevcut konfigürasyon dosyalarının yedeğini alın.
• Config değişikliğinin versiyon kontrolünde tutulduğundan emin olun.
• Yanlış bir HSTS veya CSP kuralı durumunda eski sürüme hızla dönebilmek için net bir prosedür oluşturun.

2. Staging Ortamında Test

• Tüm başlıkları önce staging ortamında deneyin.
• CSP’yi Report-Only modu ile başlayarak gerçek ihlalleri gözlemleyin.
• Ödeme adımları, giriş/çıkış, dosya yükleme gibi kritik akışları manuel test edin.

3. Tarayıcı Konsolu ve Güvenlik Araçları

• Chrome/Firefox geliştirici araçlarında Security sekmesini kontrol edin.
• Console’da CSP ihlalleri veya karışık içerik (mixed content) uyarıları var mı bakın.
• Harici güvenlik tarayıcılarından HTTP başlık raporu alın (örneğin güvenlik başlıklarını puanlayan servisler).

4. Kullanıcı ve SEO Etkilerini İzleme

• Canlıya aldıktan sonra ilk 24–72 saatte destek taleplerini yakından takip edin.
• Özellikle ödeme sayfaları, entegrasyon iframe’leri, üçüncü parti widget’lar sorun çıkarıyor mu kontrol edin.
• HTTPS ve HSTS geçişlerinde SEO dengesini korumak için HTTPS geçiş rehberindeki adımları uyguladığınızdan emin olun.

DCHost Altyapısında Bu Başlıkları Yönetmek

DCHost olarak, paylaşımlı hosting, VPS, dedicated ve colocation ortamlarımızda müşterilerimizin sitelerini yayına alırken HTTP güvenlik başlıklarını mimari tasarımın bir parçası olarak ele alıyoruz. Özellikle e‑ticaret ve SaaS projelerinde, ilk kurulum aşamasında:

• SSL/TLS yapılandırmasını modern protokollerle uyumlu hale getiriyor,
• Otomatik yenilenen SSL sertifikaları (Let’s Encrypt vb.) ile HTTPS sürekliliğini sağlıyor,
• HSTS’i aşamalı şekilde devreye alma planı öneriyor,
• Uygulama gereksinimlerinize göre temel bir CSP iskeleti oluşturuyoruz.

Daha gelişmiş kurulumlarda, CSP nonceleri, raporlama endpoint’leri, çok kiracılı (multi-tenant) SaaS’ler için ayrı CSP profilleri gibi ihtiyaçlarınızda da mimari destek veriyoruz. Eğer uygulamanız zaten VPS sunucu güvenliği odaklı bir planla kurgulandıysa, bu başlıklar o planın kritik bir tamamlayıcısı haline geliyor.

Özet ve Sonraki Adımlar

HSTS, CSP, X‑Frame‑Options ve Referrer‑Policy başlıkları, kağıt üzerinde birkaç satırlık ayarlarmış gibi görünse de, aslında tarayıcı tarafındaki güvenlik mimarinizin omurgasını oluşturuyor. HSTS ile kullanıcıyı her zaman şifreli kanala zorluyor, CSP ile hangi içeriğin hangi şartlarda yükleneceğini tanımlıyor, X‑Frame‑Options ile clickjacking riskini azaltıyor, Referrer-Policy ile de ziyaretçi verisinin nereye, ne kadar detayla gideceğini kontrol altına alıyorsunuz.

Doğru yaklaşım; bu başlıkları birer “ekstra puan” değil, temel gereklilik olarak görmek. Önce sağlam bir HTTPS ve SSL/TLS temeli kurun, ardından staging ortamında test ederek bu başlıkları kademeli biçimde devreye alın. İhtiyaç duyduğunuzda, DCHost üzerindeki hosting, VPS veya dedicated altyapınızda bu ayarları birlikte gözden geçirebilir, hem güvenlik hem performans açısından dengeli bir profil oluşturabiliriz.

Eğer sitenizde henüz bu başlıklar tanımlı değilse, ilk adım olarak mevcut yanıtlarınızı inceleyin, ardından bu rehberdeki örnekleri küçük adımlarla uygulamaya başlayın. Daha geniş perspektifte, HTTP başlıkları, SSL/TLS, DNSSEC, loglama ve yedekleme politikalarınızı bir arada ele almak için hem HTTP güvenlik başlıkları genel rehberimize hem de 3‑2‑1 yedekleme stratejisi yazımıza göz atmanızı öneririm. Güvenlik, tek bir ayarla değil; birbirini tamamlayan pek çok katmanın uyumuyla gerçekten sağlam hale geliyor.