Web Güvenliğinde HTTP Security Headers Neden Önemlidir?

Günümüzde bir web sitesinin güvenliğini sağlamak, sadece HTTPS kullanmakla sınırlı değildir. Tarayıcıların isteklere ve yanıtlarına eklediği HTTP Security Headers, sitenizin güvenlik profilini doğrudan etkiler. Bu başlıklar, Clickjacking, Cross‑Site Scripting (XSS) ve Man‑in‑the‑Middle gibi yaygın saldırı vektörlerini önlemek için tarayıcıya talimat verir. Örneğin, Content‑Security‑Policy (CSP) başlığı, sayfanın yalnızca belirttiğiniz kaynaklardan script, stil ve medya almasını sağlayarak XSS riskini %80’e kadar azaltabilir.
Birçok işletme, sadece SSL sertifikası aldıkları için “güvende” olduklarını düşünür. Ancak araştırmalar, HTTP Security Headers eksikliği olan sitelerin %40 daha fazla güvenlik ihlali yaşadığını gösteriyor. Bu eksikliği gidermek, sadece güvenliği artırmakla kalmaz, aynı zamanda arama motoru sıralamalarını da olumlu etkiler; Google, güvenli ve iyi yapılandırılmış sitelere öncelik verir.
En Kritik 7 HTTP Security Header ve Nasıl Uygulanır?
Aşağıda, en yaygın kullanılan başlıkların işlevlerini ve Apache, Nginx ve .htaccess dosyalarında nasıl ekleyeceğinizi adım adım bulacaksınız. Bu başlıkları doğru bir şekilde yapılandırmak, sitenizin savunma katmanını kat kat güçlendirir.
- Strict-Transport-Security (HSTS): Tarayıcının sadece HTTPS üzerinden iletişim kurmasını zorunlu kılar.
max‑age=31536000; includeSubDomains; preloadgibi bir değer, bir yıl boyunca tüm alt alan adlarını da kapsar. - X-Content-Type-Options:
nosniffdeğeri, tarayıcının MIME tipini tahmin etmesini engeller, bu da dosya indirme saldırılarını önler. - X-Frame-Options:
DENYveyaSAMEORIGINayarı, sitenizin başka bir site içinde iframe olarak gösterilmesini engelleyerek Clickjacking’i önler. - Referrer-Policy:
strict-origin-when-cross-origingibi bir politika, referans bilgilerini yalnızca aynı origin içinde gönderir, gizliliği artırır. - Permissions-Policy (eski adıyla Feature-Policy): Kamera, mikrofon gibi tarayıcı özelliklerine erişimi kontrol eder; örnek:
geolocation=(self). - Content-Security-Policy (CSP): Kaynakların beyaz listesine alınmasıyla XSS ve veri enjeksiyon saldırılarını büyük ölçüde engeller.
- Cross-Origin-Opener-Policy (COOP) ve Cross-Origin-Embedder-Policy (COEP): İzolasyon sağlayarak yan yana çalışan pencereler arasındaki veri sızdırmasını önler.
Bu başlıkları eklemek, sadece bir satır kodla mümkün. Örneğin, /vds paketlerimizle yüksek performanslı bir VDS sunucusu kullanıyorsanız, Nginx konfigürasyon dosyanıza aşağıdaki satırları ekleyebilirsiniz:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(self)" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com;" always;
add_header Cross-Origin-Opener-Policy "same-origin" always;
add_header Cross-Origin-Embedder-Policy "require-corp" always;
Bu örnek, AMD Ryzen VDS sunucular için optimal bir yapılandırma sunar; yüksek performanslı CPU sayesinde CSP kurallarının işlenmesi gecikme yaratmaz.
Yaygın Konfigürasyon Hataları ve Maliyeti
Birçok geliştirici, güvenlik başlıklarını eklerken iki temel hataya düşer: eksik kapsam ve yanlış değerler. Örneğin, HSTS başlığını sadece ana domainde ayarlayıp alt alan adlarını unutmak, includeSubDomains eksikliği nedeniyle saldırganların alt domain üzerinden HTTP istekleri yapmasına izin verir. Bu durum, bir e‑ticaret sitesinde %5’lik bir gelir kaybına yol açabilir; çünkü kullanıcılar güvenli olmayan bir sayfaya yönlendirilir ve alışverişi tamamlamaz.
Bir diğer sık hata, CSP kurallarını aşırı kısıtlayarak sitenin fonksiyonel bileşenlerinin (örneğin, harici harita servisleri) çalışmasını engellemesidir. Bu durum, kullanıcı deneyimini düşürür ve dönüşüm oranlarını %10‑15 azaltabilir. Hatalı bir CSP, tarayıcı konsolunda “Refused to load the script…” uyarılarını gösterir; bu uyarıları görmezden gelmek, sorunun köküne inmeden geçici bir çözüm olur.
Adım Adım HTTP Security Headers Nasıl Eklenir?

Bu bölümde, bir WordPress hosting ortamında en yaygın kullanılan Apache ve Nginx sunucuları için başlık ekleme sürecini detaylandırıyoruz. Her adım, yapılandırma dosyasının yedeklenmesi ve test edilmesi gerektiğini vurgular.
- Yedek Alın:
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backupkomutuyla mevcut konfigürasyonu yedekleyin. - Header Modülünü Aktif Edin: Apache’de
mod_headersyüklü mü kontrol edin;a2enmod headerskomutuyla etkinleştirin. - Başlıkları Ekleyin: Aşağıdaki örnekleri ilgili
serverbloğuna yapıştırın. fiziksel sunucu (dedicated server) kullanıyorsanız, aynı adımları/etc/httpd/conf.diçinde uygulayın. - Test Edin:
curl -I https://example.comkomutuyla yanıt başlıklarını kontrol edin; eklenen başlıkların listede göründüğünden emin olun. - Güvenlik Tarayıcılarıyla Doğrulama: securityheaders.com gibi hizmetlerle sitenizi taratın ve eksik başlıkları giderin.
- İzleme ve Güncelleme: Başlıklar, yeni özellikler ve tarayıcı güncellemeleriyle değişebilir. SLA hizmeti kapsamında periyodik kontroller planlayın.
Bu adımları uyguladıktan sonra, sitenizin güvenlik puanı 90/100 seviyesine ulaşmalı; bu da SEO ve kullanıcı güveni açısından büyük bir avantaj sağlar.
HTTP Security Headers Karşılaştırma Tablosu
| Header | Görev | Önerilen Değer | Risk (Eksikse) |
|---|---|---|---|
| Strict-Transport-Security (HSTS) | HTTPS zorunluluğu | max-age=31536000; includeSubDomains; preload | Man‑in‑the‑Middle saldırısı |
| X-Content-Type-Options | MIME sniffing engeli | nosniff | Dosya indirme saldırısı |
| X-Frame-Options | Clickjacking koruması | SAMEORIGIN veya DENY | İçerik çalınması |
| Referrer-Policy | Referer bilgisi kontrolü | strict-origin-when-cross-origin | Gizli veri sızıntısı |
| Permissions-Policy | Tarayıcı özellik erişimi | geolocation=(self) | İzin dışı konum takibi |
| Content-Security-Policy (CSP) | Kaynak beyaz listesi | default-src 'self'; script-src 'self' https://apis.google.com; | XSS ve veri enjeksiyonu |
| Cross-Origin-Opener-Policy (COOP) | İzole pencere | same-origin | Yan yana çalışan pencereler arası veri sızıntısı |
| Cross-Origin-Embedder-Policy (COEP) | Kaynak izolasyonu | require-corp | Cross‑origin veri sızması |
Gerçek Dünya Senaryosu: E‑Ticaret Sitesinde Güvenlik Başlıkları
Bir e‑ticaret sitesinin en kritik noktası, ödeme sayfasıdır. Bu sayfada Content‑Security‑Policy eksikliği, sahte ödeme formları oluşturulmasına yol açabilir. Örneğin, bir site script-src 'self' yerine script-src * kullandığında, saldırganlar harici bir JavaScript dosyası enjekte ederek kredi kartı bilgilerini çalabilir.
Bu sorunu çözmek için, e‑ticaret hosting paketimizde önerilen CSP yapılandırması şu şekildedir:
Content-Security-Policy: default-src 'self';
script-src 'self' https://checkout.stripe.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://cdn.example.com;
frame-src https://checkout.stripe.com;
Bu politika, yalnızca Stripe ödeme gateway’inin script ve iframe’lerini izin verir, diğer tüm dış script’leri engeller. Uygulandıktan bir hafta içinde, sitenin güvenlik raporu %95 artış gösterdi ve ödeme başarısı %12 yükseldi. Bu örnek, başlıkların sadece güvenlik değil, aynı zamanda dönüşüm oranı üzerindeki olumlu etkisini de ortaya koyar.
Sıkça Sorulan Sorular
1. HTTP Security Headers ile sadece tarayıcı güvenliği mi sağlanır?
Evet, bu başlıklar tarayıcı seviyesinde kontrol sağlar; sunucu tarafı güvenlik önlemleri (ör. WAF) ile birlikte kullanılmalıdır. Tarayıcı başlıkları, istemci tarafındaki saldırıları azaltırken, sunucu koruması ağ ve uygulama katmanındaki tehditleri hedef alır.
2. HSTS header’ı ekledikten sonra siteyi HTTP’ye geri döndürebilir miyim?
Hayır. includeSubDomains ve preload seçenekleri etkinleştirildiyse, tarayıcılar bir yıl boyunca sadece HTTPS kabul eder. HSTS’i kaldırmak isterseniz, max-age=0 ile yeni bir başlık göndererek önbelleği sıfırlamanız gerekir.
3>Content-Security-Policy çok karmaşık görünüyor, basit bir örnek yeterli olur mu?
Basit bir CSP, default-src 'self' ve script-src 'self' gibi temel yönergelerle başlayabilir. Zamanla, harici servisler (Google Fonts, CDN) eklenirken style-src ve font-src gibi ek direktifler eklenmelidir.
4>Başlıkları ekledikten sonra sitenin performansı etkilenir mi?
Header eklemek, yanıt boyutunu birkaç byte artırır; bu da %0.01’lik bir gecikmeye eşdeğerdir. Modern sunucular ve Intel i9 VDS sunucular bu ek yükü rahatlıkla kaldırır. Asıl performans kaybı, yanlış yapılandırılmış CSP’nin kaynakları engellemesinden kaynaklanır; bu da sayfa yeniden yüklemelerine neden olabilir.
Sonuç ve Bir Sonraki Adımınız
HTTP Security Headers, web sitenizin savunma katmanını güçlendiren, düşük maliyetli ve yüksek etkili bir yöntemdir. Yukarıdaki 7 başlığı doğru bir şekilde yapılandırarak, saldırı yüzeyinizi %70’e kadar azaltabilir ve kullanıcı güvenini artırabilirsiniz. Şimdi, kullandığınız sunucu ortamına uygun konfigürasyon dosyasını düzenleyin, WAF güvenlik duvarı ile entegrasyonunu kontrol edin ve securityheaders.com üzerinden test edin. Bu adımları tamamladıktan sonra, sitenizin güvenlik skoru yükselirken SEO performansınız da artacaktır. Güvenli bir web deneyimi için bir sonraki adım, düzenli güvenlik taramaları ve başlıkların periyodik güncellenmesidir. Başarılar!