HTTP Güvenlik Başlıkları Rehberi: Shared Hosting ve VPS’te CSP, HSTS, X‑Frame‑Options ve Diğerleri Nasıl Ayarlanır?

HTTP güvenlik başlıkları neden bu kadar kritik?

SSL sertifikanızı kurup sitenizi HTTPS’e taşıdığınızda önemli bir eşiği geçmiş oluyorsunuz; ancak tarayıcı tarafındaki güvenlik kontrolleri bununla bitmiyor. Modern tarayıcılar, HTTP güvenlik başlıkları sayesinde sitenizi XSS, clickjacking, karışık içerik ve istemci taraflı veri sızıntıları gibi bir dizi riske karşı daha etkili şekilde koruyabiliyor. DCHost tarafında yaptığımız güvenlik denetimlerinde gördüğümüz tablo genellikle aynı: Güzel bir HTTPS kurulumu, düzgün çalışan bir uygulama… ama HSTS kapalı, CSP yok, X-Frame-Options tanımsız ve Referrer-Policy tamamen tarayıcının varsayılanına bırakılmış.

Bu yazıda, özellikle paylaşımlı hosting (shared) ve VPS ortamlarında en çok ihtiyaç duyulan başlıkları adım adım ele alacağız: CSP (Content-Security-Policy), HSTS (Strict-Transport-Security), X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy ve yeni nesil bazı başlıklar. Hem .htaccess üzerinden çalışan klasik Apache/LiteSpeed paylaşımlı hosting senaryosunu, hem de Nginx / Apache çalışan VPS senaryosunu ayrı ayrı göstereceğiz. Eğer konuya daha konsept düzeyinde bir giriş yapmak isterseniz, öncesinde HTTP güvenlik başlıklarını ne zaman ve nasıl uygulamanız gerektiğini anlattığımız rehbere de göz atabilirsiniz.

Temel HTTP güvenlik başlıklarının kısa özeti

Detaylı yapılandırmaya girmeden önce, en kritik başlıkların ne işe yaradığını netleştirelim.

Content-Security-Policy (CSP)

Content-Security-Policy, tarayıcıya şu sorunun cevabını verir: "Bu sayfada hangi kaynaktan hangi tip içerikler (script, stil, resim, iframe vb.) yüklenebilir?" Doğru kurgulanmış bir CSP;

• XSS saldırılarının etkisini büyük ölçüde azaltır,
• Beklenmeyen 3. parti script ve iframe gömülmesini engeller,
• Mixed content ve yanlış yapılandırmaların raporlanmasını sağlar.

Örnek bir temel CSP:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; 
  script-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';

CSP oldukça derin bir konu, bu nedenle detaylı senaryolar (nonce, hash, report-to vb.) için ayrıca WordPress ve Laravel üzerinde CSP’yi doğru kurmayı anlattığımız rehbere de mutlaka bakmanızı öneririz.

Strict-Transport-Security (HSTS)

Strict-Transport-Security (HSTS), tarayıcıya "Bu siteye daima HTTPS üzerinden bağlan" talimatı verir. Böylece;

• Kullanıcı http:// yazsa bile tarayıcı otomatik olarak https:// sürüme geçer,
• Pasif bazı downgrade ve MITM senaryolarının etkisi azalır,
• HTTPS’e tam geçiş yaptıktan sonra kararlılığı artırır.

Tipik bir HSTS başlığı:

Strict-Transport-Security: max-age=31536000; includeSubDomains

HSTS için özellikle ilk geçişte dikkat edilmesi gereken noktalar var; HTTP → HTTPS sürecini planlarken SEO kaybı yaşamadan HTTPS’e geçiş, HSTS ve canonical ayarlarını anlattığımız rehber işinize yarayacaktır.

X-Frame-Options ve frame-ancestors

X-Frame-Options, sayfanızın başka siteler tarafından iframe içinde görüntülenip görüntülenemeyeceğini kontrol eder. Clickjacking saldırılarını azaltmak için önemlidir.

• X-Frame-Options: DENY → Hiçbir yerde iframe içinde gösterilemez.
• X-Frame-Options: SAMEORIGIN → Sadece aynı origin (alan adı + port) içinde iframe olarak kullanılabilir.

Yeni nesil CSP ile birlikte frame-ancestors yönergesi de benzer işi yapar. Örneğin:

Content-Security-Policy: frame-ancestors 'self';

Güncel yaklaşım, mümkünse hem X-Frame-Options hem de CSP içindeki frame-ancestors’u aynı mantıkla kullanmaktır.

X-Content-Type-Options, Referrer-Policy, Permissions-Policy

• X-Content-Type-Options: nosniff
  Tarayıcının içerik tipini "tahmin etmeye" çalışmasını engeller, özellikle dosya indirme / script yükleme senaryolarında önemlidir.
• Referrer-Policy
  Tarayıcının istekle birlikte ne kadar referrer (nereden geldiği) bilgisi göndereceğini belirler. Önerilen güvenli ve pratik değer: strict-origin-when-cross-origin.
• Permissions-Policy (eski Feature-Policy)
  Kamera, mikrofon, konum, fullscreen, payment gibi API’lerin nerede ve nasıl çalışabileceğini kısıtlamaya yarar.

Diğer başlıklar ve çerez tarafı

Bunlara ek olarak Cross-Origin-Opener-Policy (COOP), Cross-Origin-Embedder-Policy (COEP), Cross-Origin-Resource-Policy (CORP) gibi yeni nesil başlıklar; özellikle SPA, PWA ve karmaşık frontend mimarilerinde önem kazanıyor. Ayrıca güvenlik başlıklarınızı tamamlarken Set-Cookie üstünden Secure, HttpOnly ve SameSite parametrelerini de doğru kurmanız gerekiyor; bunun için SameSite, Secure ve HttpOnly çerez ayarlarını adım adım anlattığımız rehbere göz atabilirsiniz.

Paylaşımlı hosting (.htaccess) üzerinde HTTP güvenlik başlıkları

Paylaşımlı hosting kullananların büyük çoğunluğu, Apache veya LiteSpeed tabanlı bir platform üzerinde .htaccess dosyasıyla yapılandırma yapar. DCHost paylaşımlı hosting platformlarında da en pratik yol budur. Genel mantık şu:

• Alan adınızın public_html veya kök dizininde bir .htaccess dosyası bulunur.
• mod_headers etkinse, Header set veya Header always set direktiflerini kullanarak başlık ekleyebilirsiniz.
• Aynı sitede çalışan CMS (WordPress vb.) kendi kural bloklarını ekleyebilir; güvenlik başlıklarını bu blokların üstünde veya altında tutmak genelde sorun yaratmaz, ancak tekrar eden başlıkları engellemek için tek bir yerde tanımlamaya dikkat edin.

.htaccess içinde temel güvenlik başlıkları örneği

Aşağıdaki örnek, çoğu kurumsal site, blog veya temel e-ticaret sitesi için güvenli bir başlangıç noktasını temsil eder. Canlıya almadan önce staging ortamında test etmenizi öneririz.

<IfModule mod_headers.c>
  # HTTPS'i zorunlu kıl (HSTS) - sadece siteniz tamamen HTTPS ise
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

  # Clickjacking koruması
  Header always set X-Frame-Options "SAMEORIGIN"

  # İçerik tipi tahminini kapat
  Header set X-Content-Type-Options "nosniff"

  # Referrer bilgisi için dengeli ayar
  Header set Referrer-Policy "strict-origin-when-cross-origin"

  # Kamera, mikrofon vb. izinleri varsayılan olarak kapat
  Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"

  # Basit ve temkinli bir CSP örneği
  Header set Content-Security-Policy "default-src 'self'; img-src 'self' data:; 
    script-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';"
</IfModule>

Buradaki CSP örneği özellikle WordPress gibi inline stil kullanan sistemlerin bozulmaması için 'unsafe-inline' içeriyor. Bu, XSS açısından ideal değil ama CSP’siz bir dünyaya göre yine de ciddi bir iyileşme. Zaman içinde nonce ve hash tabanlı CSP‘ye geçerek bu kısmı da sıkılaştırabilirsiniz.

Paylaşımlı hostingte .htaccess ile çalışırken dikkat edilmesi gerekenler

• Cache / CDN etkisi: Önbelleğe alınmış cevaplarda eski başlıklar kalabilir. Değişiklik sonrası tarayıcı önbelleğini ve CDN önbelleğini temizleyin.
• Çift başlık sorunu: Bazı güvenlik eklentileri kendi başlıklarını gönderir. Aynı başlığın birden fazla kez set edilmesi uyarılara yol açabilir; eklenti ayarlarını gözden geçirin.
• WordPress güvenlik eklentileri: Birçok eklenti HSTS, X-Frame-Options vb. başlıkları kurabiliyor. Önce eklentideki ilgili ayarları devre dışı bırakıp hepsini .htaccess tarafında merkezileştirmek daha kontrollü bir mimari sağlar.

VPS üzerinde Nginx ve Apache için HTTP güvenlik başlıkları

VPS üzerinde kök erişiminiz olduğunda, başlıkları .htaccess yerine doğrudan sunucu yapılandırma dosyalarına eklemeniz çok daha performanslı ve temiz olur. DCHost VPS platformlarında da önerdiğimiz yaklaşım bu: Nginx veya Apache sanal host (vhost) tanımlarınızda güvenlik başlıklarını merkezi olarak yönetmek.

Nginx için örnek güvenlik başlıkları (server bloğu)

Tipik bir Nginx site tanımında kullanılabilecek örnek blok:

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

    # ... SSL ve diğer ayarlar ...

    # HSTS (site tamamen HTTPS'e geçtiyse)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # X-Frame-Options
    add_header X-Frame-Options "SAMEORIGIN" always;

    # İçerik tipi tahminini kapat
    add_header X-Content-Type-Options "nosniff" always;

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

    # Permissions-Policy (ihtiyaca göre genişletilebilir)
    add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

    # Basit CSP örneği
    add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; 
      script-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';" always;

    # ... root, index, proxy_pass vb. ayarlar ...
}

Nginx tarafında always parametresi, 4xx ve 5xx cevaplar da dahil tüm yanıtlarda başlıkların gönderilmesini sağlar. Bu, hata sayfalarınızın da aynı güvenlik politikasına tabi olmasını sağlar.

Apache vhost içinde güvenlik başlıkları

Apache tabanlı bir VPS’te, ilgili sanal host tanımı içine aşağıdaki gibi bir blok ekleyebilirsiniz:

<VirtualHost *:443>
    ServerName ornekalanadi.com
    ServerAlias www.ornekalanadi.com
    DocumentRoot /var/www/ornekalanadi.com/public

    # ... SSL sertifika ayarları ...

    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
        Header always set X-Frame-Options "SAMEORIGIN"
        Header set X-Content-Type-Options "nosniff"
        Header set Referrer-Policy "strict-origin-when-cross-origin"
        Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
        Header set Content-Security-Policy "default-src 'self'; img-src 'self' data:; 
          script-src 'self'; style-src 'self' 'unsafe-inline'; frame-ancestors 'self';"
    </IfModule>

    # ... Log ve diğer ayarlar ...
</VirtualHost>

Değişiklikten sonra konfigürasyonun hatasız olduğundan emin olmak için:

apachectl configtest
systemctl reload apache2   # veya httpd

komutlarını kullanmayı unutmayın.

CSP’yi shared hosting ve VPS’te güvenli şekilde devreye almak

CSP, bir başlıkla "ekledim bitti" diyebileceğiniz basitlikte değil; iyi yapılandırılmadığında sitenizi bozabilir. Özellikle WordPress, Laravel, SPA framework’leri (React, Vue, Angular) ve 3. parti script’lerin yoğun kullanıldığı projelerde, adım adım ilerlemek şart.

1. Content-Security-Policy-Report-Only ile başlamak

Hem paylaşımlı hosting, hem de VPS ortamında ilk adım olarak rapor modunu öneriyoruz. Örneğin Nginx için:

add_header Content-Security-Policy-Report-Only 
  "default-src 'self'; img-src 'self' data:; script-src 'self'; 
   style-src 'self' 'unsafe-inline'; frame-ancestors 'self';" always;

Bu başlık aktifken tarayıcı kısıtlama uygulamaz, sadece ihlalleri raporlar. Raporları takip etmek için report-uri veya report-to yönergelerini kullanabilir, ileride bu raporları merkezi log sisteminize taşımayı düşünüyorsanız VPS log yönetimi ve merkezi loglama rehberimize de göz atabilirsiniz.

2. Üretim moduna geçiş: Content-Security-Policy

Raporları birkaç gün izledikten sonra beklenmedik bloklamalar görmüyorsanız, Content-Security-Policy-Report-Only yerine gerçek Content-Security-Policy başlığını göndermeye başlayabilirsiniz. Dikkat etmeniz gerekenler:

• 3. parti script ve CDN’ler: analytics, tag manager, canlı destek, harita vb. servisleri script-src, img-src ve connect-src yönergelerine eklemeyi unutmayın.
• inline script ve stil: Mümkün olduğunca inline kullanımı azaltın; kalan kısım için nonce veya hash tabanlı yaklaşımı değerlendirin.
• iframes: iframe ile gömülen video / ödeme / harita servislerinin alan adlarını frame-src veya child-src yönergelerine ekleyin.

Gelişmiş CSP kurguları için, nonce ve hash kullanımı ile ilgili örnekleri detaylı şekilde CSP’yi doğru kurma rehberimizde bulabilirsiniz.

HSTS’i ne zaman ve nasıl açmalısınız?

HSTS yanlış zamanda açıldığında, özellikle karma bir HTTPS geçiş sürecindeyseniz, beklenmedik yönlendirme döngüleri ve alt alan adı problemleri yaratabilir. DCHost tarafında müşterilerimizle çalışırken genelde şu yol haritasını öneriyoruz:

1. Adım: Tüm trafiği HTTPS’e zorla yönlendirin

Önce HTTP isteklerini güvenli şekilde HTTPS’e yönlendirdiğinizden emin olun (.htaccess veya Nginx/Apache kuralı ile). Bu aşamada HSTS henüz kapalı olabilir.

2. Adım: Bir süre izleyin, mixed content hatalarını temizleyin

Tarayıcı konsolunda ve mixed content ve güvensiz içerik hatalarını düzeltme rehberimizde anlattığımız kontrollerle, sitenizde kalan tüm http:// içerik çağrılarını temizleyin.

3. Adım: HSTS’i kısa bir max-age ile açın

İlk etapta örneğin 1 gün veya 1 hafta gibi kısa bir max-age kullanabilirsiniz:

Strict-Transport-Security: max-age=604800; includeSubDomains

Herhangi bir problem yaşamadığınızdan emin olduktan sonra süreyi 6 ay veya 1 yıla uzatabilirsiniz. HSTS preload (tarayıcı listelerine girmek) ise son aşamadır; tüm alt alan adlarınızın HTTPS’e %100 hazır olduğundan emin olmadan bu adıma geçmeyin.

X-Frame-Options, Referrer-Policy ve diğer başlıklar için önerilen değerler

Shared hosting ve VPS ortamları için genelde şu kombinasyonları öneriyoruz:

• X-Frame-Options: Çoğu site için SAMEORIGIN güvenli ve yeterlidir. Hiçbir yerde iframe olarak gösterilmesini istemiyorsanız DENY kullanabilirsiniz. Ödeme sayfaları ve kritik formlar için daha katı ayarlar tercih edilebilir.
• Referrer-Policy: strict-origin-when-cross-origin hem analitik veriyi çok bozmaz, hem de gereksiz tam URL sızıntılarını engeller. Daha agresif gizlilik istiyorsanız same-origin veya no-referrer düşünebilirsiniz.
• X-Content-Type-Options: Her zaman nosniff.
• Permissions-Policy: İhtiyaç duymadığınız API’leri komple kapatın. Örneğin tipik bir kurumsal site için: geolocation=(), microphone=(), camera=(), payment=().

Bu başlıkları daha genel bir perspektiften incelemek isterseniz, HSTS, CSP, X-Frame-Options ve Referrer-Policy’yi doğru kurma rehberimiz de işin teorik kısmını pekiştirmenize yardımcı olacaktır.

Shared hosting ve VPS için pratik kontrol listesi

Makalenin bu noktasına kadar olan kısmı, gerçek hayatta sıkça kullandığımız bir kontrol listesine dönüştürebiliriz. Paylaşımlı hosting veya VPS kullanıyor olmanız fark etmiyor; mantık aynı, sadece uygulama yeri değişiyor.

1. En az şu başlıklar mutlaka olmalı

• Strict-Transport-Security (HSTS) – HTTPS geçişi tamamlandıysa
• X-Frame-Options veya CSP içindeki frame-ancestors
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy (temel kısıtlamalar)
• Content-Security-Policy (en azından basit bir "default-src ‘self’" seviyesi)

2. Shared hosting için uygulanabilir adımlar

1. cPanel veya benzeri panelden dosya yöneticisine girin, sitenizin kök dizinindeki .htaccess dosyasını bulun.
2. Önce mevcut içeriğin yedeğini alın.
3. Yukarıda verdiğimiz örnek Header direktiflerini, <IfModule mod_headers.c> ... </IfModule> bloğu içinde ekleyin.
4. Kaydedin, sitenizi yeni bir tarayıcı sekmesinde açıp Geliştirici Araçları > Network sekmesinden cevap başlıklarını kontrol edin.
5. Tarayıcı konsolunda (Console) CSP ile ilgili hata mesajlarını takip ederek gerekirse alan adı eklemeleri yapın.

3. VPS için uygulanabilir adımlar

1. Sunucunuzun üzerinde Nginx mi, Apache mi (veya ikisi birden) çalıştığını netleştirin.
2. İlgili siteye ait konfigürasyon dosyasını bulun (Nginx için genelde /etc/nginx/sites-available/alanadi.conf, Apache için /etc/apache2/sites-available/alanadi.conf veya benzeri).
3. Yukarıdaki server/vhost örneklerindeki add_header veya Header set bloklarını uygun yere ekleyin.
4. Konfigürasyon testi yapın ve servisi yeniden yükleyin (reload).
5. Gerekirse staging ortamında A/B test yaparak, başlıkların uygulamayı bozmadığından emin olun.

Sonuç: Güvenlik başlıkları olmadan HTTPS tam sayılmaz

HTTPS’e geçmiş olmak, güvenliğin temel adımı ama sonu değil. HTTP güvenlik başlıkları olmadan; tarayıcı sizin yerinize bir dizi varsayım yapıyor ve bu varsayımlar her zaman güvenlikten yana değil. Özellikle XSS, clickjacking, mixed content ve istemci taraflı veri sızıntıları gibi sorunlar, doğru başlıklarla çok daha kontrol edilebilir hale geliyor. Shared hosting kullanıyorsanız .htaccess üzerinden, VPS kullanıyorsanız doğrudan Nginx/Apache yapılandırmasıyla bu korumaları devreye almak mümkün.

DCHost olarak, ister paylaşımlı hosting ister VPS veya dedicated altyapı kullanın, yeni açılan her projede HTTP güvenlik başlıkları kontrol listesini zorunlu bir adım gibi düşünmenizi öneriyoruz. Mevcut sitenizde bu başlıkların durumundan emin değilseniz, barındırma ortamınız DCHost üzerindeyse destek ekibimize ticket açarak birlikte gözden geçirebiliriz; ya da bu yazıdaki örnekleri adım adım uygulayıp tarayıcı geliştirici araçlarıyla sonucu hemen test edebilirsiniz. Güvenlik tarafını bir kerelik bir iş değil, sürekli bakım yapmanız gereken bir süreç olarak ele aldığınızda; loglama, sertifika güncellemeleri, çerez politikaları ve HTTP güvenlik başlıkları bir bütün olarak çok daha iyi çalışacaktır.