Güvenlik Başlıkları (Security Headers): Her Biri Ne Yapar ve Nasıl Kurulur

Kısaca: Güvenlik başlıkları, sunucunuzun her sayfayla birlikte gönderdiği ve tarayıcılara şunları söyleyen talimatlardır: her zaman HTTPS kullan, betikleri yalnızca onayladığınız kaynaklardan çalıştır, başka sitelerin sayfalarınızı çerçeveye almasına izin verme, dosya türlerini tahmin etme ve tam URL'leri Referer başlığının dışında tut. Her yerde HTTPS ve geçerli bir sertifikayla başlayın, ardından Strict-Transport-Security, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin ve frame-ancestors ya da X-Frame-Options ekleyin. Content-Security-Policy başlığını önce yalnızca rapor modunda (report-only) devreye alın. Hepsi sunucu veya CDN yapılandırmasında ayarlanır.

Güvenlik başlıkları ucuz bir sigortadır. Çoğu tek satırlık sunucu yapılandırmasıyla eklenir, performansa maliyeti yoktur ve bütün saldırı türlerini engeller: oturum çalan enjekte edilmiş bir betik, insanları tıklamaya kandıran görünmez bir çerçeve, ziyaretçiyi düz HTTP'ye düşüren bir kafe ağı. Ayrıca güvenlik tarayıcılarının, kurumsal müşterilerin ve güvenlik anketlerinin ilk baktığı şeyler arasındadır.

Bu rehber her başlığı ve çevresindeki bağlantı temellerini açıklar, güvenli başlangıç değerleri verir, ücretsiz güvenlik başlıkları denetleyicimizin sitenizi nasıl test ettiğini gösterir ve bildirdiği her sorun için düzeltme adımlarını anlatır.

Önce temeller: HTTPS, sertifika ve karışık içerik

Başlıklar şifreli bir bağlantının üzerinde çalışır; bağlantı şifreli değilse işe yaramazlar. Önce üç temel:

• Her sayfada HTTPS ve HTTP'nin yönlendirilmesi. Temmuz 2018'deki Chrome 68'den beri Chrome her HTTP sayfasını "güvenli değil" olarak işaretliyor (Chromium Blog). Google'ın sayfa deneyimi rehberi de şunu soruyor: "Are your pages served in a secure fashion?"
• Kullandığınız tüm host adlarını kapsayan geçerli bir sertifika; www ve çıplak alan adı dahil. Süresi dolmuş veya eşleşmeyen bir sertifika tam sayfa uyarı gösterir.
• Karışık içerik (mixed content) olmaması. Dosyaları http:// üzerinden yükleyen güvenli bir sayfa tam güvenli değildir. MDN'e göre tarayıcılar görselleri, sesi ve videoyu otomatik olarak HTTPS'e yükseltir; betikleri, stil dosyalarını, iframe'leri ve diğer "engellenebilir" içeriği ise doğrudan engeller, bu da sayfayı bozar.

Başlıklar tek tek

Strict-Transport-Security (HSTS)

HSTS, tarayıcıya host'unuz için belirli bir saniye boyunca HTTPS kullanmasını söyler; biri http:// yazsa ya da eski bir bağlantıya tıklasa bile. MDN bilmeniz gereken üç noktayı belirtir:

• Tarayıcılar, düz HTTP üzerinden gelen başlığı yok sayar. Başlığı HTTPS yanıtlarında gönderin; HTTP'den HTTPS'e yönlendirmenizin buna ihtiyacı yoktur.
• Yalnızca ilk güvenli ziyaretten sonra çalışır. Preload bu boşluğu kapatır.
• includeSubDomains politikayı tüm alt alan adlarına uygular, bu yüzden önce hepsini kontrol edin.

HSTS preload listesi alan adınızı tarayıcılara sabit olarak yazar. Geçerli bir sertifika, aynı host üzerinde HTTP'den HTTPS'e yönlendirme, HTTPS üzerindeki tüm alt alan adları ve en az 31536000 max-age, includeSubDomains ve preload içeren bir başlık gerektirir. Ayrıca "inclusion in the preload list cannot easily be undone" uyarısı yapar: kaldırmanın kullanıcılara ulaşması aylar sürer. Preload'u yalnızca emin olduğunuzda kullanın.

Content-Security-Policy (CSP)

CSP başlıkların en güçlüsü ve devreye alması en zor olanıdır. Betiklerin, stillerin, görsellerin ve diğer kaynakların nereden yüklenebileceğini listeler; tarayıcı geri kalan her şeyi reddeder. MDN onu esas olarak "a defense against cross-site scripting (XSS) attacks" olarak tanımlar.

Önerilen modern biçim, uzun alan adı izin listeleri yerine nonce veya hash tabanlı sıkı bir CSP'dir:

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

Nonce rastgele olmalı ve her yanıtta farklı olmalıdır. MDN, 'unsafe-inline' kullanımının "defeats much of the purpose of having a CSP" olduğunu uyarır.

Sıkı bir politika analitik etiketlerini, sohbet widget'larını ve satır içi betikleri bozabileceğinden iki adımda devreye alın: önce bir raporlama uç noktasıyla Content-Security-Policy-Report-Only gönderin, raporların gösterdiklerini düzeltin, sonra zorunlu kılan başlığa geçin. upgrade-insecure-requests de CSP içinde yer alır (karışık içerik için bir güvenlik ağıdır, HSTS'in yerini tutmaz) ve çerçevelemeyi frame-ancestors denetler.

X-Frame-Options ve frame-ancestors

Clickjacking, sayfanızı başka bir sitede görünmez bir çerçeve içinde yükler ve insanları butonlarınıza tıklamaya kandırır. Engellemenin iki yolu var:

• X-Frame-Options: SAMEORIGIN (veya DENY), eski başlık. ALLOW-FROM kullanım dışıdır ve modern tarayıcıların başlığı yok saymasına yol açar.
• Content-Security-Policy: frame-ancestors 'self', daha esnek seçenek; belirli iş ortağı origin'lerini de listeleyebilir.

Hiçbiri <meta> etiketinde çalışmaz. MDN, meta öğesindeki X-Frame-Options'ın "has no effect" olduğunu ve frame-ancestors'ın "is not supported in the <meta> element" olduğunu belirtir. Ayrıca frame-ancestors default-src'ye geri dönmez: default-src 'none' politikası da sayfanın herkes tarafından çerçevelenmesine izin verir.

X-Content-Type-Options

nosniff, tarayıcılara Content-Type başlığınıza güvenmelerini söyler. Bununla, betik veya stil dosyası olarak istenen bir yanıt MIME türü uyuşmuyorsa engellenir; böylece görsel gibi gösterilen yüklenmiş bir dosya betik olarak çalışamaz. Tek geçerli değeri vardır:

X-Content-Type-Options: nosniff

Eklemeden önce sunucunuzun, özellikle JavaScript ve CSS için doğru content type'ları gönderdiğinden emin olun.

Referrer-Policy

Bir ziyaretçi başka bir siteye giden bağlantıya tıkladığında tarayıcı bir Referer başlığı gönderir. Modern tarayıcılar zaten varsayılan olarak strict-origin-when-cross-origin kullanır; bu, siteler arası geçişte yalnızca origin'i (https://example.com/) gönderir, HTTPS'ten HTTP'ye geçişte ise hiçbir şey göndermez (MDN). OWASP yine de bunu "rather than relying on browser defaults" açıkça ayarlamayı önerir. İçindeki token'lar dahil tam URL'leri her yere gönderen unsafe-url'den kaçının.

Permissions-Policy ve kaldırılması gereken başlıklar

Permissions-Policy, kullanmadığınız tarayıcı özelliklerini kapatır; böylece gömülü bir betik kamera veya konum isteyemez. MDN bunu sınırlı tarayıcı desteğiyle deneysel olarak işaretler, bu yüzden ek bir katman olarak düşünün. Ücretsiz denetleyicimiz bunu test etmez; tam güvenlik taraması eder.

Eklemek yerine kaldırılması gereken iki başlık: OWASP, X-XSS-Protection'ı ayarlamamanızı (veya 0 yapmanızı) söyler, çünkü denetlediği eski filtreler güvenlik açıkları yaratabiliyordu; Expect-CT'yi ise kullanım dışı olarak niteler. Ayrıca X-Powered-By'ı kaldırmanızı ve Server'a bilgi vermeyen bir değer atamanızı önerir.

Searvia güvenlik başlıkları denetleyicisi nasıl çalışır

Ücretsiz güvenlik başlıkları denetleyicisi, web sitesi SEO denetleyicimizle aynı motoru çalıştırır ve beş kontrolü öne alır. Herhangi bir ziyaretçinin yapabileceği sıradan istekler yapar; hiçbir şeye saldırılmaz veya sızma denemesi yapılmaz.

Saydığı üç başlık Content-Security-Policy, X-Frame-Options (veya frame-ancestors içeren bir CSP başlığı) ve X-Content-Type-Options'dır. Referrer-Policy de listelenir, ancak eksik olması aleyhinize sayılmaz: tarayıcılar zaten varsayılan olarak strict-origin-when-cross-origin kullanır ve tablo bunu belirtir. Sonuç tablosu her başlığın değerini gösterir; uzun politikalar kısaltılır.

Aklınızda tutmanız gereken bazı sınırlar:

• Varlığı kontrol eder, kaliteyi değil. İçi 'unsafe-inline' dolu bir CSP burada geçer; bunu tam güvenlik taraması derecelendirir.
• HTTP yanıt başlıklarını okur. <meta> etiketinde ayarlanan CSP bir notla birlikte sayılır: frame-ancestors ve raporlama orada çalışmaz, bu yüzden X-Frame-Options'ın yerini tutamaz. Content-Security-Policy-Report-Only başlığı zorunlu kılınan bir politika sayılmaz.
• Tek bir sayfayı kontrol eder; girdiğiniz sayfayı (yalnızca alan adı girerseniz ana sayfayı). Yönetim paneli veya API gibi diğer yollar farklı başlıklar gönderebilir.
• Karışık içerik yalnızca HTML'de bulunur: etiketlerdeki mutlak http:// URL'leri. CSS veya JavaScript tarafından sonradan istenen dosyalar görülmez.

Sonuçlar nasıl okunur

Önceliğe göre yukarıdan aşağıya ilerleyin. Başarısız bir HTTPS veya sertifika kontrolü acildir: ziyaretçiler tarayıcı uyarıları görür veya şifresiz bağlanır. Sırada aktif karışık içerik (betikler, iframe'ler, stil dosyaları) gelir; çünkü tarayıcılar bu dosyaları engeller ve sayfa bozulabilir. HSTS ve güvenlik başlıkları skorda düşük önceliklidir, ancak en hızlı düzeltilenler de bunlardır; hepsini tek bir yapılandırma değişikliğinde toplayın.

Denetleyicinin bildirdiği her sorun nasıl düzeltilir

"The site does not work over HTTPS." / "HTTP does not redirect to HTTPS."

1. Bir sertifika kurun. Let's Encrypt ücretsizdir ve çoğu hosting tek tıkla sunar.
2. Her http:// URL'sinden aynı https:// URL'sine kalıcı yönlendirme ekleyin.

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Cloudflare'de SSL/TLS › Edge Certificates altında "Always Use HTTPS" seçeneğini açın.

"The certificate expired N days ago." / "The certificate does not cover this domain."

1. Hemen yenileyin ve otomatik yenilemeyi açın (Certbot ile çoğu hosting ve CDN bunu varsayılan olarak yapar).
2. Sertifikanın sunduğunuz tüm host adlarını, en azından çıplak alan adını ve www'yu listelediğinden emin olun.
3. Yenileme sessizce başarısız oluyorsa olağan nedenler değişmiş bir DNS kaydı, engellenmiş bir doğrulama yolu veya DNS doğrulaması için süresi dolmuş bir API token'ıdır.

14 günden az kaldığını söyleyen bir uyarı genellikle otomatik yenilemenin çalışmadığı anlamına gelir; her seferinde elle yenilemek yerine nedenini araştırın.

"HSTS is not set." / "HSTS is on but shorter than 6 months."

Unutulmuş, yalnızca HTTP çalışan bir alt alan adının dışarıda kalmaması için kademeli devreye alın:

1. Ana sitenin ve tüm alt alan adlarının HTTPS üzerinde çalıştığını doğrulayın.
2. Bir gün boyunca Strict-Transport-Security: max-age=300, ardından bir hafta (604800), sonra bir ay gönderin.
3. max-age=31536000; includeSubDomains değerine geçin.
4. Ancak o zaman preload'u düşünün ve hstspreload.org'a başvurun.

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

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

"N files load over plain HTTP."

1. Rapordaki URL listesini açın.
2. Her birini https:// olarak değiştirin; kendi dosyalarınız için göreli yola çevirin. Üçüncü taraf dosyalarda sağlayıcının HTTPS sunduğunu kontrol edin; sunmuyorsa sağlayıcıyı değiştirin.
3. Veritabanınızda ve temanızda sabit kodlanmış http:// bağlantılarını arayın; HTTPS'e geçişten sonra genellikle eski yazı içerikleri kaynaktır.
4. Güvenlik ağı olarak Content-Security-Policy: upgrade-insecure-requests ekleyin.

"N key security headers are missing."

Eksik olanları tek değişiklikte ekleyin. nginx için:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy-Report-Only "default-src 'self'; frame-ancestors 'self'; report-to csp" always;

Apache için:

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

Cloudflare'de yanıt başlıklarını bir Transform Rule ile ekleyin. Netlify'da _headers dosyasını, Vercel'de vercel.json içindeki headers ayarını kullanın. nginx'te bir location bloğundaki add_header'ın server düzeyinde ayarlanan başlıkların yerini aldığını unutmayın; bu yüzden onları tekrarlayın veya bir include dosyası kullanın.

CSP için yukarıdaki report-only satırı bitmiş bir politika değil, bir başlangıç noktasıdır. report-to'yu kontrol ettiğiniz bir raporlama uç noktasına yönlendirin, ihlalleri bir iki hafta inceleyin, politikayı ayarlayın, ardından başlığın adını Content-Security-Policy olarak değiştirin. Zorunlu kılındığında CSP kontrolü geçer.

Başlıkları kendiniz nasıl kontrol edersiniz

Denetleyici, kontrol edilen sayfanın gönderdiğini gösterir; ancak diğer sayfalar, dosyalar ve hata yanıtları farklı olabilir. Bakmanın iki hızlı yolu:

• Tarayıcı DevTools. Network panelini açın, sayfayı yenileyin, ilk isteğe tıklayın ve Response Headers bölümünü okuyun.
• Komut satırı. curl -sI https://www.example.com/ yalnızca yanıt başlıklarını yazdırır. Bunu ana sayfa, derin bir sayfa, bir PDF, bir 404 sayfası ve giriş sayfanız için çalıştırın.

Sık rastlanan bir sürpriz, normal sayfalarda görünen ama hata ve yönlendirme yanıtlarında görünmeyen başlıklardır. nginx'te always parametresini eklemediğiniz sürece add_header yalnızca başarılı ve yönlendirme yanıtlarına uygulanır; yukarıdaki her örneğin onu içermesinin nedeni budur. Bir diğeri, başlık ekleyen veya silen bir CDN ya da hosting'dir; bu yüzden yalnızca sunucu yapılandırma dosyanıza değil, herkesin gördüğü yanıta bakın.

Her başlığın farklı bir şeyi koruduğunu unutmayın. Mükemmel bir CSP, süresi dolmuş bir sertifika için hiçbir şey yapmaz; HSTS de enjekte edilmiş bir betiğe karşı işe yaramaz. Hedef, makul bir sırayla eklenmiş bütün set'tir.

Örnek senaryo (varsayımsal)

Aşağıdaki örnek varsayımsaldır, gerçek veri değildir. Uydurma bir hukuk bürosu olan Halden Legal, kurumsal bir müşteriden web sitesi başlıklarını soran bir güvenlik anketi alır. Güvenlik başlıkları denetleyicisi şunu bildirir:

• HTTPS, TLS sertifikası: geçti, 61 gün kaldı.
• HSTS: uyarı, max-age=86400 (bir gün).
• Karışık içerik: uyarı, 2 görsel HTTP üzerinden yükleniyor (bir iş ortağı rozeti ve eski bir ekip fotoğrafı).
• Güvenlik başlıkları: 2 temel başlık eksik; yalnızca X-Content-Type-Options ayarlı ve Referrer-Policy tarayıcı varsayılanını gösteriyor.

Düzeltmeler bir öğleden sonra sürer. İki görsel URL'si HTTPS olarak değiştirilir. Müşteri portalı alt alan adının HTTPS üzerinde çalıştığı doğrulandıktan sonra HSTS, bir hafta içinde iki adımda max-age=31536000; includeSubDomains değerine çıkarılır. Sunucuda X-Frame-Options: SAMEORIGIN ve Referrer-Policy: strict-origin-when-cross-origin eklenir. Report-only bir CSP on gün çalışır ve randevu widget'ından gelen satır içi bir betiği ortaya çıkarır; politika zorunlu kılınmadan önce bu betik bir dosyaya taşınır ve origin'i ile izin verilir. Son çalıştırma tüm kontrolleri geçer ve büro anketi paylaşılan raporun bağlantısıyla yanıtlar.

Bir saatlik kontrol listesi

1. Güvenlik başlıkları denetleyicisini çalıştırın ve önce HTTPS ile sertifika hatalarını düzeltin.
2. Raporda listelenen karışık içeriği kaldırın.
3. X-Content-Type-Options, Referrer-Policy ve X-Frame-Options veya frame-ancestors ekleyin.
4. Tüm alt alan adları HTTPS üzerinde çalışınca HSTS'i kademeli olarak bir yıla çıkarın.
5. Report-only bir CSP başlatın ve bir inceleme planlayın.
6. X-Powered-By'ı, Server içindeki sürüm numaralarını ve 0 dışındaki her X-XSS-Protection değerini kaldırın.

Searvia sitenizin güvenliğini nasıl izler

Ücretsiz güvenlik başlıkları denetleyicisi ana sayfanızı veya girdiğiniz herhangi bir sayfayı yaklaşık 20 saniyede, kayıt gerektirmeden kontrol eder; aynı rapor arama görünümü, tarama, hız, mobil ve e-posta kimlik doğrulaması hakkında 33 kontrol daha içerir.

Ücretsiz bir Searvia hesabı haftalık bir güvenlik taraması ekler: şifreleme, tarayıcı korumaları, çerez bayrakları, yazılım sürümleri ve e-posta sahteciliği korumasına yönelik pasif kontroller; her bulguyu kanıtlayan istek ve yanıtla birlikte. CSP'nizi derecelendirir (örneğin nonce veya hash olmadan 'unsafe-inline'), Permissions-Policy'yi kontrol eder ve sahipliği doğruladıktan sonra açığa çıkmış .env ve .git dosyalarını, herkese açık yedekleri, hata ayıklama sayfalarını ve güvensiz CORS'u da arar. Write the remediation plan with AI bulguları yapıştırabileceğiniz yapılandırmaya dönüştürür (5 kredi). Starter'dan başlayan ücretli planlarda uptime izleme ayrıca TLS sertifikanızı her gün kontrol eder ve süresi dolmadan sizi uyarır.