Güvenlik Başlıkları (HTTP Security Headers) Nasıl Yapılandırılır?

HTTP güvenlik başlıkları, web sunucunuzun her yanıtla birlikte tarayıcıya gönderdiği talimatlardır ve bütün bir saldırı sınıfını daha ziyaretçinin tarayıcısında engeller. XSS, clickjacking, protokol düşürme ve içerik türü karıştırma gibi yaygın saldırıların çoğu, doğru yapılandırılmış birkaç başlıkla etkisiz hale gelir. En güzel yanı, bu korumanın kod değişikliği gerektirmemesi; birkaç satır sunucu yapılandırmasıyla eklenebilmesidir.

Bu rehberde en önemli altı güvenlik başlığını tek tek ele alıyoruz: her birinin ne işe yaradığını, Apache ve Nginx için örnek yapılandırmasını ve sonucu nasıl test edeceğinizi gösteriyoruz. Değişiklikleri yaptıktan sonra web sunucusunu yeniden yüklemeyi (reload) unutmayın.

1. Content-Security-Policy (CSP): XSS'e Karşı En Güçlü Kalkan

Content-Security-Policy, tarayıcıya sayfada hangi kaynaklardan (script, stil, resim, çerçeve) içerik yükleyebileceğini bildirir. Böylece saldırganın enjekte ettiği bir script, izin verilen kaynaklar listesinde olmadığı için çalıştırılmaz. CSP, XSS saldırılarına karşı elinizdeki en güçlü savunmadır, ancak aynı zamanda en dikkatli yapılandırılması gereken başlıktır çünkü fazla katı bir politika sitenizin kendi kaynaklarını da engelleyebilir.

Başlangıç için makul ölçüde katı bir politika, yalnızca kendi alan adınızdan yüklemeye izin verir. Nginx için:

add_header Content-Security-Policy "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'" always;

Bu satır, script ve diğer kaynakların yalnızca kendi sitenizden yüklenmesine izin verir; resimlere gömülü data: URI'lerini ve satır içi stillere esneklik tanır. CSP'yi doğrudan zorunlu kılmak yerine önce Content-Security-Policy-Report-Only başlığıyla test edip hangi kaynakların engellendiğini gözlemlemenizi, ardından gerçek politikaya geçmenizi öneririz. Uygulamanıza göre CSP'yi ince ayar yapmak zaman ister; sunucu genelinde doğru yapılandırma için Linux sunucu sıkılaştırma hizmetimiz bu yükü üstlenir.

CSP yazarken en sık yapılan hata, 'unsafe-inline' ve 'unsafe-eval' gibi izinleri gereksiz yere açık bırakmaktır; bunlar politikanın XSS koruması sağladığı asıl noktayı büyük ölçüde etkisiz kılar. Modern bir yaklaşımda satır içi scriptler için nonce ya da hash değerleri kullanılarak yalnızca bilinen ve onaylı betiklerin çalışmasına izin verilir. Ayrıca dış analitik ya da yazı tipi servisleri kullanıyorsanız bunların alan adlarını ilgili yönergelere (script-src, font-src) açıkça eklemeniz gerekir; aksi halde bu kaynaklar engellenir. CSP'yi kademeli olarak sıkılaştırmak, hem güvenliği hem de site işlevselliğini korur.

2. Strict-Transport-Security (HSTS): HTTPS'i Zorunlu Kılar

HSTS, tarayıcıya siteye yalnızca HTTPS üzerinden bağlanmasını söyler ve bir kez alındıktan sonra kullanıcı http:// yazsa bile bağlantıyı otomatik olarak güvenliye çevirir. Bu, araya girip şifrelemeyi kaldırmaya çalışan (SSL stripping) saldırıları etkisiz hale getirir. HSTS'nin ön koşulu, sitenizin ve tüm alt alan adlarınızın HTTPS'te kusursuz çalışıyor olmasıdır.

Nginx için sunucu bloğuna eklenecek satır:

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

Bu başlık, tarayıcıya siteye ve tüm alt alan adlarına bir yıl boyunca yalnızca HTTPS ile bağlanmasını söyler. includeSubDomains yalnızca tüm alt alan adlarınız HTTPS destekliyorsa eklenmelidir. Henüz SSL kurmadıysanız ya da HTTPS'e yeni geçtiyseniz, önce SSL/HTTPS kurulumu rehberimizi tamamlayıp ardından HSTS'yi açın.

HSTS'de dikkat edilmesi gereken bir nokta, max-age değerinin kalıcılığıdır. Tarayıcı bu süreyi bir kez öğrendiğinde, siz başlığı sonradan kaldırsanız bile o süre boyunca siteye ısrarla HTTPS ile bağlanmaya devam eder. Bu yüzden HSTS'yi test aşamasında kısa bir süreyle (örneğin birkaç dakika) deneyip her şeyin yolunda olduğundan emin olduktan sonra bir yıllık değere geçmek daha güvenlidir. preload yönergesini eklemek ve sitenizi tarayıcıların ön yükleme listesine kaydettirmek ise en yüksek koruma düzeyini sağlar, ancak bu adım geri alması zor bir taahhüt olduğundan yalnızca HTTPS altyapınız tamamen oturduğunda düşünülmelidir.

3. X-Frame-Options: Clickjacking'i Engeller

X-Frame-Options, sitenizin başka bir sitenin iframe çerçevesi içine gömülmesini engelleyerek clickjacking saldırılarını önler. Clickjacking'de saldırgan, sitenizi görünmez bir çerçeveye alıp kullanıcının farkında olmadan üzerinde işlem yapmasını sağlar; bu başlık bu tekniği kaynağında keser. Özellikle giriş ve işlem sayfaları olan siteler için önemlidir.

Apache için .htaccess ya da sunucu yapılandırmasına eklenecek satır:

Header always set X-Frame-Options "SAMEORIGIN"

Bu satır, sitenizin yalnızca kendi alan adınız içindeki çerçevelere gömülmesine izin verir, dış sitelerin çerçevelemesini engeller. Sitenizin hiçbir yerde çerçevelenmesini istemiyorsanız SAMEORIGIN yerine DENY kullanabilirsiniz. Daha modern ve esnek kontrol için CSP'nin frame-ancestors yönergesi de aynı işi görür; ikisini birlikte kullanmak geniş tarayıcı uyumu sağlar. Ödeme, hesap ayarları ve yönetim panelleri gibi hassas sayfalarda bu başlığı istisnasız uygulamak, kullanıcının bilgisi dışında bir işleme yönlendirilmesini önlemenin en basit yoludur.

4. X-Content-Type-Options: MIME Karıştırmayı Durdurur

X-Content-Type-Options başlığı, tarayıcının bir dosyanın türünü "tahmin etmesini" (MIME sniffing) engeller. Bu tahmin mekanizması, saldırganın zararsız görünen bir dosyayı (örneğin bir resmi) tarayıcıya script gibi çalıştırtmasına yol açabilir. Tek bir değeri vardır ve istisnasız her sitede açık olmalıdır.

Nginx için:

add_header X-Content-Type-Options "nosniff" always;

Bu satır tarayıcıya, sunucunun bildirdiği içerik türüne sadık kalmasını ve dosya türünü tahmin etmemesini söyler. Yan etkisi neredeyse hiç yoktur, bu yüzden tereddütsüz eklenmesi gereken en güvenli başlıklardan biridir. Ekledikten sonra sitenizin normal çalışmaya devam ettiğini kontrol etmeniz yeterlidir. Bu başlığın işe yaraması için sunucunuzun dosyalara doğru içerik türünü (Content-Type) göndermesi gerektiğini unutmayın; yanlış yapılandırılmış MIME türleri, nosniff açıkken kaynakların yüklenmemesine yol açabilir.

5. Referrer-Policy: Sızan Bilgiyi Sınırlar

Referrer-Policy, kullanıcı sitenizden başka bir siteye tıkladığında hangi adres bilgisinin (referrer) karşı tarafa gönderileceğini denetler. Varsayılan davranışta, ziyaret edilen sayfanın tam URL'si üçüncü taraflara sızabilir; bu URL'de oturum belirteçleri ya da hassas parametreler varsa gizlilik sorunu doğar. Bu başlık, ne kadar bilginin paylaşılacağını sizin belirlemenizi sağlar.

Apache için dengeli bir değer:

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Bu değer, aynı siteye geçişlerde tam adresi paylaşır, dış sitelere geçişte ise yalnızca alan adını gönderir ve HTTPS'ten HTTP'ye geçişte hiçbir şey sızdırmaz. Hem işlevselliği hem gizliliği koruyan makul bir dengedir. Daha katı bir gizlilik istiyorsanız no-referrer kullanabilirsiniz, ancak bu bazı analitik araçlarını etkileyebilir. Referrer bilgisinin sızması özellikle URL'lerinde parola sıfırlama belirteçleri ya da davet kodları taşıyan siteler için ciddi bir risktir; bu tür sayfalarda daha katı bir politika uygulamak, hassas parametrelerin üçüncü taraflara ulaşmasını tümüyle engeller.

6. Permissions-Policy: Tarayıcı Özelliklerini Kısıtlar

Permissions-Policy, sitenizin ve içine gömülen üçüncü taraf içeriklerin kamera, mikrofon, konum gibi hassas tarayıcı özelliklerine erişimini denetler. Kullanmadığınız özellikleri kapatarak, olası bir XSS ya da kötü niyetli bir üçüncü taraf scriptin bu donanımlara erişmesini engellersiniz. En az yetki ilkesinin tarayıcı katmanındaki karşılığıdır.

Nginx için, kullanılmayan hassas özellikleri kapatan bir örnek:

add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;

Bu satır, siteniz üzerinden konum, mikrofon ve kamera erişimini tamamen kapatır. Sitenizin bu özelliklerden birine gerçekten ihtiyacı varsa, ilgili özelliği self ile yalnızca kendi alan adınıza açabilirsiniz. Kullanmadığınız her özelliği kapatmak, saldırı yüzeyinizi daraltmanın kolay bir yoludur. Bu başlık, özellikle sayfanıza reklam ya da widget gibi üçüncü taraf içerikler gömüyorsanız değer kazanır; çünkü o içeriklerin ziyaretçinizin donanımına erişmesini varsayılan olarak engelleyerek gizlilik açısından da bir koruma sağlar.

7. Yapılandırmayı Test Edin ve Doğrulayın

Başlıkları eklemek yeterli değildir; gerçekten yanıtla birlikte gönderildiğini ve beklediğiniz değeri taşıdığını doğrulamanız gerekir. Yanlış yerde tanımlanmış ya da yeniden yüklenmemiş bir yapılandırma, başlığın hiç görünmemesine yol açar. Doğrulama, hem başlığın varlığını hem de içeriğini kontrol etmelidir.

En hızlı test, komut satırından yanıt başlıklarını çekmektir:

curl -I https://site.com

Bu komut sitenin yanıt başlıklarını listeler; eklediğiniz güvenlik başlıklarının burada göründüğünü doğrulayabilirsiniz. Tarayıcının geliştirici araçlarındaki "Network" sekmesinden de aynı başlıkları görebilir, çevrimiçi güvenlik başlığı tarayıcılarıyla politikanızın kalitesini puanlayabilirsiniz. Değişiklik yaptıktan sonra Nginx'te nginx -t && systemctl reload nginx, Apache'de apachectl configtest && systemctl reload apache2 ile yapılandırmayı sınayıp yeniden yükleyin. Başlıkların yanı sıra genel güvenlik durumunuzu ölçmek için ücretsiz sunucu güvenlik kontrolü ile eksikleri raporlayabiliriz.

Sık Sorulan Sorular

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

Hayır. Güvenlik başlıkları yanıt başlığına eklenen birkaç satırdan ibarettir ve ölçülebilir bir performans etkisi yaratmaz. Aksine HSTS ve CSP gibi başlıklar, gereksiz yönlendirmeleri ve güvensiz kaynak yüklemelerini azaltarak dolaylı olarak deneyimi iyileştirebilir.

Hangi güvenlik başlığından başlamalıyım?

Yan etkisi olmayan ve tereddütsüz eklenebilecek olanlardan başlayın: X-Content-Type-Options, X-Frame-Options ve Referrer-Policy. Ardından HTTPS'iniz sağlamsa HSTS'yi ekleyin. Content-Security-Policy'yi en sona bırakın, çünkü sitenizin kaynaklarına göre dikkatli ayar gerektirir; önce rapor modunda test edin.

Content-Security-Policy sitemin bir kısmını bozdu, ne yapmalıyım?

CSP çok katıysa sitenizin kendi script ya da stillerini de engelleyebilir. Çözüm, politikayı doğrudan zorunlu kılmadan önce Content-Security-Policy-Report-Only başlığıyla çalıştırıp tarayıcı konsolunda hangi kaynakların engellendiğini görmektir. Engellenen meşru kaynakları izinli listeye ekledikten sonra gerçek politikaya geçin.

Başlıkları Apache mi Nginx mi olduğunu nasıl anlarım?

Sunucunuzu genellikle host paneliniz ya da nginx -v / apache2 -v komutlarıyla belirleyebilirsiniz. Reverse proxy kullanan kurulumlarda başlıkları en dıştaki sunucuda (çoğu zaman Nginx) tanımlamak en güvenilir yoldur. Emin değilseniz her ikisinin de örnek yapılandırmasını bu rehberde bulabilirsiniz.

Güvenlik başlıkları tek başına yeterli mi?

Hayır. Güvenlik başlıkları güçlü bir tarayıcı katmanı savunması sağlar, ancak HTTPS, güncel yazılım, güçlü kimlik doğrulama ve izleme gibi diğer katmanların yerini tutmaz. Katmanlı savunmanın tamamını görmek için web sitesi güvenliği nasıl sağlanır rehberimizi inceleyin.

---

Sitenizin güvenlik başlıklarının doğru yapılandırılıp yapılandırılmadığını tahmin etmek yerine ölçelim: ücretsiz sunucu güvenlik kontrolü ile başlıklarınızı, SSL yapılandırmanızı ve açık portlarınızı tek raporda çıkarıyoruz. CSP gibi karmaşık başlıklarda takılırsanız WhatsApp üzerinden 7/24 ulaşabilir, uçtan uca yapılandırma için Linux sunucu sıkılaştırma hizmetimizden yararlanabilirsiniz.