HTTP Güvenlik Başlıkları Rehberi

Bir web sunucusu, tarayıcıya sadece HTML ve resim göndermez; her yanıtın başında görünmeyen bir dizi HTTP başlığı da yollar. Bu başlıklar tarayıcıya "bu sayfayı nasıl işlemesi gerektiğini" söyler. Güvenlik başlıkları da tam olarak bu mekanizmayı kullanır: tarayıcıya bir dizi kural dayatarak, saldırganın kötüye kullanabileceği davranışları kapatırlar. Doğru yapılandırıldıklarında sitenizin kod tabanına tek satır dokunmadan clickjacking, MIME karıştırma ve veri sızıntısı gibi tüm bir saldırı sınıfını devre dışı bırakabilirsiniz.

En güzel tarafı, bu başlıkların uygulanmasının çoğu zaman birkaç satırlık sunucu yapılandırmasından ibaret olmasıdır. Yıllardır sunucu yöneten biri olarak söyleyebilirim ki, bir sitenin güvenlik seviyesini en hızlı yükselten müdahalelerden biri budur; maliyeti neredeyse sıfır, kazancı ise ciddi. Bu rehberde hangi başlığın hangi saldırıyı engellediğini tek tek anlatacak, Nginx ve Apache için hazır örnekler vereceğim ve sonunda securityheaders.com ile aldığınız puanı nasıl doğrulayacağınızı göstereceğim. Amaç, bu yazıyı okuyup bitirdiğinizde kendi sitenizin başlıklarını gönül rahatlığıyla düzenleyebilmeniz.

HTTP Güvenlik Başlıkları Nedir ve Neden Gerekir#

Her HTTP yanıtı iki bölümden oluşur: gövde (içeriğin kendisi) ve başlıklar (içerik hakkındaki üst veri). Content-Type, Cache-Control, Set-Cookie gibi başlıkları çoğunuz duymuşsunuzdur. Güvenlik başlıkları da aynı yerde, HTTP/1.1 200 OK satırının hemen ardından gider ve tarayıcıya davranışsal sınırlar koyar.

Bu başlıkların kritik bir özelliği vardır: uygulanmalarını tarayıcı üstlenir, sunucu değil. Yani sunucu "bu sayfa iframe içine gömülemez" der, kuralı fiilen uygulayan ise ziyaretçinin tarayıcısıdır. Bu yüzden güncel bir tarayıcı bu koruma için şarttır; ama pratikte Chrome, Firefox, Safari ve Edge'in modern sürümleri tümünü destekler.

Neden gerekli olduklarını bir örnekle netleştireyim. Diyelim ki e-ticaret sitenizin ödeme sayfası var. Saldırgan kendi sahte sitesine sizin ödeme sayfanızı görünmez bir iframe olarak gömüp, üstüne sahte butonlar yerleştirerek kullanıcıyı farkında olmadan "Öde" butonuna tıklatabilir. Sunucunuzda tek bir açık yoktur, kodunuz kusursuzdur; ama tarayıcı sayfanızı iframe'e gömmesine izin verdiği için saldırı çalışır. İşte X-Frame-Options başlığı tam da bu senaryoyu engeller. Güvenlik başlıkları, kodunuzdaki açıkları kapatmaz; kodunuz kusursuz olsa bile tarayıcının kötüye kullanılmasını önler. Bu ikisi birbirini tamamlar.

Aşağıdaki tablo, bu yazıda ele alacağımız temel başlıkları ve karşıladıkları tehdidi özetliyor.

X-Frame-Options ile Clickjacking'i Durdurmak#

Clickjacking, Türkçesiyle "tıklama hırsızlığı", saldırganın sitenizi şeffaf bir iframe içine gömüp kullanıcıyı yanıltarak tıklama yaptırmasıdır. Kullanıcı aslında sahte bir "hediye kazandınız" butonuna bastığını sanırken, alttaki görünmez katmanda hesabını silen veya para transferini onaylayan gerçek butona basmış olabilir.

X-Frame-Options başlığı, sayfanızın hangi kaynaklarda iframe içine alınabileceğini denetler. İki pratik değeri vardır. DENY hiçbir sitede, kendi siteniz dahil, sayfanın frame'e gömülmesine izin vermez. SAMEORIGIN yalnızca aynı alan adı içindeki frame'lere izin verir; başka bir siteden gömme girişimini engeller. Çoğu site için doğru tercih SAMEORIGIN'dir, çünkü kendi içinizde meşru gömme ihtiyaçlarını korurken dışarıdan gelen saldırıyı keser.

X-Frame-Options: SAMEORIGIN

Buradaki tek incelik şudur: X-Frame-Options eski ama hâlâ geçerli bir başlıktır. Modern muadili Content-Security-Policy içindeki frame-ancestors yönergesidir ve daha esnektir; örneğin birden fazla güvenilir alan adına izin verebilirsiniz. En sağlam yaklaşım ikisini birlikte kullanmaktır: X-Frame-Options eski tarayıcılar için güvenlik ağı olur, frame-ancestors ise modern tarayıcılarda ince ayar sağlar. CSP'yi bu yazının sonunda ayrı bir başlık altında ele alacağım.

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

X-Content-Type-Options ile MIME Sniffing'i Kapatmak#

Tarayıcılar bazen sunucunun bildirdiği Content-Type değerine güvenmez ve dosyanın gerçek türünü içeriğine bakarak tahmin etmeye çalışır. Buna MIME sniffing denir. Kulağa yardımsever gibi gelse de ciddi bir güvenlik açığıdır.

Somutlaştırayım. Kullanıcıların dosya yükleyebildiği bir siteniz olsun. Saldırgan profil.jpg adında bir dosya yükler, ama dosyanın içine JavaScript kodu gömer. Sunucu bu dosyayı image/jpeg olarak sunar. Ancak MIME sniffing açıkken tarayıcı içeriğe bakar, "bu aslında script" der ve dosyayı çalıştırılabilir kod olarak işler. Böylece uzantısı .jpg olan bir dosya sitenizde XSS saldırısına dönüşür.

X-Content-Type-Options: nosniff başlığı bu tahmin oyununu tamamen kapatır. Tarayıcıya "sunucunun söylediği Content-Type neyse odur, kendi kafana göre yorumlama" der. Tek bir değeri vardır ve o değeri kullanmanız yeterlidir.

X-Content-Type-Options: nosniff

Bu başlığın hiçbir yan etkisi yoktur ve istisnasız her sitede açık olmalıdır. Uygulaması bedava, kazancı büyük olan başlıkların başında gelir. Özellikle dosya yükleme özelliği olan panellerde, forum ve CMS kurulumlarında bu başlık olmazsa olmazdır.

Referrer-Policy ile Veri Sızıntısını Önlemek#

Bir kullanıcı sitenizdeki bir bağlantıya tıklayıp başka bir siteye gittiğinde, tarayıcı varsayılan olarak hedef siteye Referer başlığında hangi sayfadan geldiğini söyler. Bu masum görünür ama tehlikeli olabilir. Diyelim ki kullanıcı https://siteniz.com/siparis/12345?token=gizli adresindeyken dış bir bağlantıya tıkladı. Referrer başlığı sayesinde o dış site, sipariş numaranızı ve URL'deki gizli tokeni öğrenmiş olur.

Referrer-Policy başlığı, tarayıcının referrer bilgisini ne kadar paylaşacağını kontrol eder. Çok sayıda değeri vardır; en çok kullanılanları şöyle özetleyeyim.

Çoğu site için dengeli ve önerilen değer strict-origin-when-cross-origin'dir. Bu değer, kendi siteniz içindeki gezinmelerde tam URL'yi (analitik için faydalı) korurken, dış sitelere geçişte yalnızca alan adınızı gönderir ve URL'deki hassas parametreleri sızdırmaz. Ayrıca HTTPS'ten HTTP'ye düşüşte referrer'ı tamamen keser. Bu davranışın anlamlı olabilmesi için sitenizin baştan sona HTTPS üzerinde çalışması gerekir; henüz yönlendirmeyi kurmadıysanız HTTPS yönlendirme rehberimiz tam size göre.

Referrer-Policy: strict-origin-when-cross-origin

Permissions-Policy ile Tarayıcı Özelliklerini Sınırlamak#

Modern tarayıcılar sitelere güçlü özellikler sunar: kamera, mikrofon, konum, hareket sensörleri, tam ekran, otomatik oynatma ve daha fazlası. Normalde bir sitenin bunları kullanabilmesi için kullanıcının izin vermesi gerekir. Ancak siteniz XSS ile ele geçirilirse veya içine gömdüğünüz üçüncü taraf bir reklam betiği kötü niyetliyse, bu özellikler kullanıcının haberi olmadan kötüye kullanılabilir.

Permissions-Policy başlığı (eski adıyla Feature-Policy), sitenizin ve içine gömülen içeriklerin hangi tarayıcı özelliklerine erişebileceğini baştan kısıtlar. Mantık basittir: kullanmadığınız her özelliği kapatın. Bir blog sitesinin kameraya, mikrofona veya ödeme API'sine ihtiyacı yoktur; bunları kapatarak saldırı yüzeyini daraltırsınız.

Söz dizimi, her özellik için izin verilen kaynak listesini alır. Boş parantez () o özelliği tamamen kapatır, (self) sadece kendi sitenize izin verir.

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=(), usb=(), fullscreen=(self)

Bu örnekte konum, kamera, mikrofon, ödeme ve USB erişimi tamamen kapalı; tam ekran ise yalnızca kendi sayfalarınıza açık. Sitenizin bir özelliğe gerçekten ihtiyacı varsa (örneğin bir harita entegrasyonu için konum), o özelliği (self) veya güvendiğiniz alan adıyla açar, gerisini kapalı tutarsınız. Kural olarak beyaz liste yaklaşımını benimseyin: varsayılan kapalı, ihtiyaç oldukça aç. Bu, en az ayrıcalık ilkesinin başlık dünyasındaki karşılığıdır.

HSTS ile HTTPS'i Zorunlu Kılmak#

Diğer başlıklara geçmeden önce, en güçlü güvenlik başlıklarından birinden söz etmezsem eksik kalır: Strict-Transport-Security, kısaca HSTS. Bu başlık tarayıcıya "bu siteye bundan sonra yalnızca HTTPS üzerinden bağlan, asla şifresiz HTTP deneme" talimatı verir.

Neden önemli? Klasik bir yönlendirme (http:// isteğini https://'e çevirme) bir kez şifresiz olarak sunucuya ulaşır ve tam bu ilk adımda araya giren saldırgan (man-in-the-middle) bağlantıyı ele geçirebilir. HSTS bu boşluğu kapatır: tarayıcı başlığı bir kez gördükten sonra, belirtilen süre boyunca adres çubuğuna http:// yazsanız bile isteği sunucuya hiç göndermeden HTTPS'e çevirir.

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

max-age=31536000 bir yıl demektir. includeSubDomains kuralı tüm alt alan adlarına yayar. preload ise sitenizi tarayıcıların önceden yüklü HSTS listesine eklemek için kullanılır; bu son direktifi eklemeden önce tüm alt alan adlarınızın HTTPS'te sorunsuz çalıştığından kesinlikle emin olmalısınız, aksi halde erişilemez hale gelebilirler. HSTS'yi ancak SSL sertifikanız düzgün kuruluysa açın; sertifika süreçlerinizi tek panelden yönetmek için SSL çözümlerimize göz atabilirsiniz.

Nginx ve Apache'de Güvenlik Başlıklarını Ekleme#

Teoriyi kapattık; sıra uygulamada. Bu başlıkları sunucu düzeyinde eklemek, her uygulamada ayrı ayrı kod yazmaktan çok daha temiz ve güvenilirdir. Aşağıda hem Nginx hem Apache için tam örnekleri veriyorum.

Nginx tarafında server bloğunun içine add_header satırlarını eklersiniz. always parametresi, hata sayfaları dahil her yanıta başlığın eklenmesini garantiler; bunu unutmayın, çünkü onsuz 404 gibi hata durumlarında başlıklar düşebilir.

server {
    listen 443 ssl;
    server_name siteniz.com;

    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 Permissions-Policy "geolocation=(), camera=(), microphone=()" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # ... diğer yapılandırma
}

Nginx'te dikkat edilecek önemli bir tuzak var: aynı bağlamda (örneğin bir location bloğunda) yeni bir add_header tanımlarsanız, üst bloktaki tüm add_header satırları geçersiz olur ve yalnızca alt bloktakiler geçerli kalır. Bu yüzden başlıkları mümkün olduğunca üst düzeyde, tek bir yerde toplamak en sağlıklısıdır. Değişiklikten sonra nginx -t ile yapılandırmayı test edip systemctl reload nginx ile devreye alın.

Apache tarafında ise mod_headers modülünün etkin olması gerekir. Başlıkları VirtualHost içine veya bir .htaccess dosyasına ekleyebilirsiniz. .htaccess yaklaşımı özellikle paylaşımlı hosting ortamlarında pratiktir çünkü sunucunun ana yapılandırmasına dokunmadan çalışır.

<IfModule mod_headers.c>
    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"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
</IfModule>

Apache'de mod_headers'ın açık olup olmadığını a2enmod headers komutuyla etkinleştirebilir, ardından systemctl restart apache2 ile yeniden başlatabilirsiniz. Bir WordPress kurulumunda çalışıyorsanız .htaccess yöntemi genellikle en hızlı yoldur; WordPress bakım ve güvenlik ayarlarını profesyonel yönetmek isterseniz WordPress bakım hizmetimiz devreye girebilir. Sunucunuzun tamamını bizim yönetmemizi tercih ederseniz sunucu yönetimi paketleri bu tür sıkılaştırmaları sizin adınıza yapar.

Eğer bir ters proxy veya CDN kullanıyorsanız (örneğin Cloudflare veya kendi Nginx proxy katmanınız), başlıkların en dış katmanda ayarlandığından emin olun. Çünkü kullanıcının tarayıcısına ulaşan son yanıt hangi katmandan çıkıyorsa, geçerli olan başlıklar oradakilerdir. Bazen alt katmanda doğru ayarlanmış bir başlık, üst katmanda ezildiği için etkisiz kalır.

securityheaders.com ile Doğrulama ve CSP'ye Köprü#

Başlıkları eklediniz; peki gerçekten çalışıyorlar mı? Bunu iki yolla doğrularsınız. İlki komut satırından, saniyeler içinde. curl ile yanıt başlıklarını çekip gözle kontrol edebilirsiniz.

curl -sI https://siteniz.com | grep -iE 'x-frame|x-content|referrer|permissions|strict-transport'

Bu komut yalnızca başlıkları (-I) ister ve grep ile ilgilendiğimiz satırları süzer. Beklediğiniz beş başlığı da çıktıda görüyorsanız, sunucu yapılandırmanız doğru çalışıyor demektir. Görmüyorsanız, büyük ihtimalle always/Header always parametresini unuttunuz veya yanlış blokta tanımladınız.

İkinci ve daha kapsamlı yöntem, ücretsiz bir çevrimiçi tarayıcı olan securityheaders.com'dur. Sitenizin adresini girersiniz, araç tüm güvenlik başlıklarınızı analiz edip size A'dan F'ye bir not verir ve eksiklerinizi tek tek listeler. İlk denemede D veya F almak son derece normaldir; bu rehberdeki beş başlığı ekledikten sonra tekrar tarattığınızda notunuzun A seviyesine çıktığını göreceksiniz. Bu, yaptığınız işin somut ve ölçülebilir bir kanıtıdır ve müşteriye rapor verirken çok işe yarar.

A+ notuna ulaşmanın son adımı ise Content-Security-Policy (CSP) başlığıdır. Şimdiye kadar anlattığım başlıklar belirli saldırıları hedefli biçimde engelliyordu; CSP ise sayfanızda hangi kaynaklardan script, stil, resim ve iframe yüklenebileceğini baştan sona tanımlayan çok daha kapsamlı bir çerçevedir. XSS saldırılarına karşı en güçlü savunma hattıdır çünkü saldırganın enjekte ettiği betiğin çalışmasını engelleyebilir.

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

CSP güçlü olduğu kadar hassastır: fazla katı bir politika sitenizin meşru betiklerini de bloklayabilir, bu yüzden önce Content-Security-Policy-Report-Only moduyla test edip nelerin bloklanacağını rapor olarak toplamak akıllıca olur. CSP başlı başına ayrı ve derin bir konudur; bu yazıdaki dört temel başlık ise CSP'ye kıyasla çok daha az risk taşır ve hemen bugün eklenebilir. Güvenlik başlıklarını uygulama katmanına gelen istekleri filtrelemekle birleştirmek isterseniz, bir web uygulama güvenlik duvarı (WAF) başlıklarla mükemmel bir ikili oluşturur; başlıklar tarayıcı davranışını sıkılaştırırken WAF kötü niyetli istekleri sunucuya varmadan durdurur.

Sıkça Sorulan Sorular#

Güvenlik başlıkları sitemi yavaşlatır mı?#

Hayır, ölçülebilir bir yavaşlama getirmezler. Bu başlıklar her yanıta eklenen birkaç yüz bayttan ibarettir ve tarayıcı tarafında işlenmeleri neredeyse anlıktır. HSTS gibi bazı başlıklar aslında performansı iyileştirir bile, çünkü tarayıcı gereksiz HTTP-HTTPS yönlendirmesini atlar. Performans endişesiyle bu başlıklardan kaçınmak için hiçbir teknik gerekçe yoktur.

X-Frame-Options ve CSP frame-ancestors aynı anda kullanılabilir mi?#

Evet ve önerilen yaklaşım tam olarak budur. X-Frame-Options eski tarayıcılar için, frame-ancestors ise modern tarayıcılar için çalışır ve modern tarayıcılar ikisini birden gördüğünde frame-ancestors yönergesini dikkate alır. İkisini birlikte tanımlamak, hem geriye dönük uyumluluğu korur hem de en geniş tarayıcı yelpazesinde koruma sağlar. Bir çakışma veya çift koruma sorunu yaşamazsınız.

Bu başlıkları eklersem WordPress veya panelim bozulur mu?#

Doğru değerlerle bu risk çok düşüktür. X-Content-Type-Options: nosniff ve Referrer-Policy gibi başlıkların pratikte hiçbir yan etkisi yoktur. Dikkat gerektirenler X-Frame-Options ve Permissions-Policy'dir: eğer sitenizi meşru olarak bir iframe içinde gösteriyorsanız DENY yerine SAMEORIGIN seçmelisiniz, kamera-mikrofon kullanan bir eklentiniz varsa da ilgili özelliği açık bırakmalısınız. En sağlıklısı, değişiklikten sonra sitenizin tüm işlevlerini bir kez test etmektir.

Sertifikam yoksa güvenlik başlıkları işe yarar mı?#

Bir kısmı yarar, ama tam koruma için HTTPS şarttır. X-Frame-Options, X-Content-Type-Options ve Permissions-Policy şifresiz HTTP üzerinde de çalışır. Ancak Strict-Transport-Security yalnızca HTTPS ile anlam taşır ve Referrer-Policy'nin HTTPS'ten HTTP'ye sızıntı koruması da ancak siteniz HTTPS'te ise devreye girer. Bu yüzden önce SSL sertifikanızı kurup HTTPS'e geçmeniz, sonra başlıkları eklemeniz en doğru sıralamadır.

En kritik güvenlik başlığı hangisidir, sadece birini seçmem gerekse?#

Tek bir başlık seçmek zorunda kalsam, uzun vadede en yüksek kaldıraç sağladığı için Content-Security-Policy derdim; ancak o daha fazla test gerektirir. Hemen bugün, riske girmeden eklenebilecek "en çok fayda getiren" başlık ise X-Content-Type-Options: nosniff'tir çünkü hiçbir yan etkisi yoktur ve tüm MIME sniffing saldırılarını kapatır. Gerçekçi olan, dört temel başlığı birlikte eklemektir; hepsi birkaç satır ve birbirini tamamlıyor.

Kapanış#

HTTP güvenlik başlıkları, güvenlik dünyasında nadir rastlanan bir fırsattır: düşük çaba, yüksek getiri. Kod tabanınıza dokunmadan, birkaç satır sunucu yapılandırmasıyla clickjacking, MIME sniffing, referrer sızıntısı ve istenmeyen tarayıcı özelliği erişimini kapatabilirsiniz. Yapmanız gereken, bu yazıdaki beş başlığı Nginx veya Apache yapılandırmanıza eklemek, curl ve securityheaders.com ile doğrulamak ve zamanla CSP'yi de işin içine katmaktır.

Bu sıkılaştırmayı kendi başınıza yapmak istemiyor ya da sunucunuzun bütününün profesyonelce yönetilmesini tercih ediyorsanız, Clou.TR olarak yardımcı olabiliriz. Hosting paketlerimiz güvenli yapılandırmalarla gelir, sunucu yönetimi hizmetimiz başlıklar dahil tüm güvenlik sıkılaştırmalarını sizin yerinize yapar, SSL çözümlerimiz ise HSTS'yi anlamlı kılan sertifikaları tek panelden yönetmenizi sağlar. Güvenli bir web varlığı kurmanın ilk adımını bugün atın; gerisini birlikte halledelim.