HTTP Güvenlik Başlıkları Rehberi: HSTS, CSP, X-Frame-Options ve Diğerleri
HTTP Güvenlik Başlıkları Rehberi: HSTS, CSP, X-Frame-Options ve Diğerleri
Son Güncelleme: Mart 2026
HTTP güvenlik başlıkları (security headers), web uygulamalarının tarayıcı tarafında maruz kalabileceği pek çok saldırıya karşı ilk savunma hattını oluşturur. Bu rehberde HSTS, CSP, X-Frame-Options, Referrer-Policy ve diğer önemli başlıkların ne olduğu, nasıl yapılandırılacağı, sunucu ve uygulama seviyesinde uygulanması ile test ve izleme yöntemleri ele alınacaktır.
İçindekiler
- HTTP Güvenlik Başlıkları Nedir?
- Neden Önemli?
- Temel Başlıklar ve Anlamları
- Nginx ve Apache: Hızlı Kurulum Örnekleri
- Uygulama Seviyesinde Uygulama ve CSP Adımları
- İzleme, Test ve Raporlama
- Sıkça Sorulan Sorular
- Sonuç
HTTP Güvenlik Başlıkları Nedir?
HTTP güvenlik başlıkları, sunucunun tarayıcıya gönderdiği ek meta bilgileridir ve tarayıcının siteyle etkileşim şeklini sınırlar veya bazı özellikleri zorunlu kılar. Bu başlıklar sayesinde clickjacking, XSS (Cross-Site Scripting), MIME type sniffing ve gizlilik sızmaları gibi riskler azaltılabilir.
Neden Önemli?
Günümüzde uygulama güvenliği sadece sunucu tarafı doğrulamalarla sağlanamaz; tarayıcı davranışını kontrol eden güvenlik başlıkları, hem saldırı yüzeyini küçültür hem de uyumluluk (compliance) ve güven hissi sağlar. Aşağıda kısa faydaları listeliyoruz:
- Saldırı Yüzeyini Azaltma: Tarayıcının bazı riskli davranışlarını engelleyerek saldırı başarısını düşürür.
- Gizlilik Yönetimi: Referrer-Policy ile hangi bilginin üçüncü-partilere gönderileceği kontrol edilir.
- Uygulama Güvenliği Katmanı: Sunucu ve uygulama güvenliği ile birlikte çok katmanlı savunma sağlar.
Temel Başlıklar ve Anlamları
En sık kullanılan başlıklar ve önerilen kısa açıklamaları:
- HSTS (Strict-Transport-Security): Tarayıcıya tüm isteklerin sadece HTTPS üzerinden yapılmasını söyler, downgrade (indirgeme) saldırılarını önler.
- CSP (Content-Security-Policy): Kaynak politikası belirleyerek hangi domainlerden script, stil, görüntü vs. yüklenebileceğini sınırlar; XSS riskini ciddi oranda azaltır.
- X-Frame-Options: Sayfanın iframe içinde gösterilmesini engelleyerek clickjacking saldırılarına karşı korur.
- X-Content-Type-Options: "nosniff" değeri ile tarayıcının MIME tipi tahmin etmesini engeller, MIME-based saldırıları azaltır.
- Referrer-Policy: Tarayıcıdan giden referer (kaynak) bilgisinin seviyesini belirler; gizlilik kontrolü sağlar.
- Permissions-Policy (eski adı Feature-Policy): Tarayıcının belirli API’lere (kamera, microphone, geolocation) erişimini domain düzeyinde sınırlar.
| Başlık | Koruduğu Risk | Önerilen Değer / Not |
|---|---|---|
| Strict-Transport-Security | Man-in-the-middle, HTTPS downgrade | max-age=31536000; includeSubDomains; preload (önce test sonrası preload). |
| Content-Security-Policy | XSS, veri hırsızlığı | Begin with restrictive policy, sonra script-src ve style-src için ihtiyaçları açın; report-to/report-uri ile raporlayın. |
| X-Frame-Options | Clickjacking | DENY veya SAMEORIGIN (iFrame gerekiyorsa frame-ancestors CSP tercih edilir). |
| X-Content-Type-Options | MIME-sniffing | nosniff |
| Referrer-Policy | Gizlilik, bilgi sızması | strict-origin-when-cross-origin veya no-referrer-when-downgrade tercih edilebilir. |
| Permissions-Policy | Tarayıcı API suistimali | Örnek: geolocation=(), microphone=() (kesin sınırlandırma önerilir). |
Nginx ve Apache: Hızlı Kurulum Örnekleri
Aşağıda temel başlıkların Nginx ve Apache için örnek konfigürasyon satırları bulunmaktadır. Bu örnekler üretime almadan önce staging ortamında test edilmelidir.
Nginx Örnek Konfigürasyon
| Başlık | Nginx Konfigürasyonu (server blok içinde) |
|---|---|
| HSTS | add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always; |
| CSP | add_header Content-Security-Policy "default-src 'self'; script-src 'self' cdn.example.com; object-src 'none';"; |
| X-Frame-Options | add_header X-Frame-Options "SAMEORIGIN"; |
| X-Content-Type-Options | add_header X-Content-Type-Options "nosniff"; |
| Referrer-Policy | add_header Referrer-Policy "strict-origin-when-cross-origin"; |
Apache (httpd) Örnek Konfigürasyon
| Başlık | Apache Konfigürasyonu (VirtualHost içinde veya .htaccess) |
|---|---|
| HSTS | Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" |
| CSP | Header set Content-Security-Policy "default-src 'self'; script-src 'self' cdn.example.com;" |
| X-Frame-Options | Header set X-Frame-Options "SAMEORIGIN" |
| X-Content-Type-Options | Header set X-Content-Type-Options "nosniff" |
Not: Apache'de mod_headers etkin olmalıdır. Nginx'de add_header yönergesi location düzeyinde davranış farkı gösterebilir; bu nedenle "always" parametresinin kullanımı önemlidir.
Uygulama Seviyesinde Uygulama ve CSP Adımları
Content-Security-Policy uygulaması genellikle en karmaşık olandır çünkü üçüncü parti script ve stil kullanımını etkiler. Aşağıdaki adımlar pratik bir uygulama rehberidir:
- Envanter Çıkarın: Site hangi kaynaklardan (CDN, analytics, reklam, widget) script/stil görüntü çekiyor tespit edin.
- Başlangıçta Rapor Modunda Çalıştırın: CSP'yi report-only modunda açın ve tarayıcı raporlarını toplayın; bu, kırılma noktalarını görmenizi sağlar.
- Kademeli Sıkılaştırma: Başlangıçta 'unsafe-inline' ve 'unsafe-eval' kullanımını minimize edin, sonra kaldırmaya çalışın.
- Nonce/Hash Kullanımı: Inline script'ler için nonce veya SHA hash kullanarak güvenli inline yürütme sağlayın.
- Otomasyon: Build sürecine CSP hash/nonce üretimini ekleyin ve CI/CD hattında test edin.
Örnek: report-only için header (Nginx): add_header Content-Security-Policy-Report-Only "default-src 'self'; report-uri /csp-report-endpoint";
İzleme, Test ve Raporlama
Uygulama güvenlik başlıklarının etkinliğini sürekli kontrol etmek, konfigürasyon değişiklikleri veya yeni üçüncü parti entegrasyonlar sonrası sorunları hızlıca yakalamanıza yardımcı olur.
- Otomatik Test: CI/CD pipeline içine security headers testleri ekleyin (ör. curl ile header kontrolü veya otomatik tarama araçları).
- Raporlama: CSP raporlarını toplayacak bir endpoint oluşturun ve raporları merkezi log/issue tracker'a gönderin.
- Gözlemleme: Web uygulama güvenlik duvarı (WAF) ile birlikte kullanıldığında, hata/engellenme olaylarını korelasyonlayın. (WAF rehberleri için ayrıca SSL Sertifikası sayfamızı ve güvenlik hizmetlerimizi inceleyin.)
Pratik Kullanım Senaryoları
- E-ticaret Siteleri: HSTS ile ödeme sayfalarında HTTPS zorunlu hale getirin; CSP ile ödeme formu script kaynaklarını sınırlandırın.
- İdari Paneller: Referrer-Policy ile hassas URL'lerin üçüncü partilere sızmasını önleyin; Permissions-Policy ile kamera/mikrofonu kapatın.
- Çoklu Alt Alan Adları: HSTS includeSubDomains kullanırken tüm alt alanların HTTPS hazır olduğundan emin olun veya belirli alt alanları istisna bırakın.
Sıkça Sorulan Sorular
HSTS nedir ve neden "preload" sıradışı bir karar olabilir?
HSTS (Strict-Transport-Security) tarayıcıya sitenizin sadece HTTPS üzerinden erişilmesi gerektiğini bildirir. "preload" olarak eklenmesi tarayıcıların önceden yüklediği HSTS listesine eklenmenizi sağlar; ancak geri dönüşü zordur. Bu nedenle önce en az bir yıl max-age ile includeSubDomains kullanıp stabiliteyi test edin, sonra preload başvurusunda bulunun.
CSP uygulaması sitenin çalışmasını bozarsa ne yapmalıyım?
Önce report-only modunda çalıştırıp hangi kaynakların engellendiğini görün. Daha sonra izinleri kademeli olarak açın veya inline scriptler için nonce/hash uygulayın. Build sürecinde CSP uyumlu hale getirme otomasyonu geliştirin.
X-Frame-Options yerine CSP kullanmak daha mı iyidir?
X-Frame-Options basit ihtiyaçlar için yeterlidir (SAMEORIGIN veya DENY). Ancak daha esnek kontrol gerekirse CSP'deki frame-ancestors direktifi tercih edilmelidir çünkü X-Frame-Options daha sınırlı ve eski tarayıcılarla sınırlıdır.
Referrer-Policy hangi durumlarda "no-referrer" olarak ayarlanmalı?
Hassas bir uygulama yönetiyorsanız (ör. ödeme, sağlık bilgileri), dış bağlantılara hiçbir referer bilgisi göndermek için no-referrer kullanılabilir. Ancak analiz/istatistik araçları için kısıtlamalar getirebilir; dengeyi göz önünde bulundurun.
Bu başlıkları uyguladıktan sonra ne sıklıkta kontrol etmeliyim?
Her konfigürasyon değişikliğinde ve tercihen haftalık veya en geç aylık otomatik testlerle. CI/CD pipeline'a basit header kontrollerini eklemek en iyi yöntemdir.
Sonuç
Özetle, HTTP güvenlik başlıkları modern web güvenliğinin vazgeçilmez bir parçasıdır. Hem sunucu hem uygulama düzeyinde doğru şekilde uygulanmaları, web sitenizi pek çok yaygın saldırıdan korur. Corelux olarak altyapınızda bu başlıkların uygulanmasında yardımcı olabiliriz; SSL yönetimi için SSL Sertifikası hizmetimiz ve hosting altyapısı ihtiyaçlarınız için Linux Hosting sayfamızı inceleyebilirsiniz. Güvenli bir geçiş için staging ortamında test, kademeli uygulama ve izleme süreçlerini ihmal etmeyin.
Bu rehberdeki adımları takip ederek sitenizin güvenliğini artırabilir, kullanıcı verilerini daha etkin koruyabilirsiniz.
Yazar
Boran BAR
