Giriş: Web Güvenliğinizin Görünmez Kalkanı - HTTP Güvenlik Başlıkları
Günümüzün sürekli gelişen siber tehdit ortamında, web uygulamalarının güvenliğini sağlamak her zamankinden daha kritik bir hale gelmiştir. Birçok geliştirici ve güvenlik uzmanı genellikle sunucu tarafı kod güvenliğine, veritabanı korumasına ve kimlik doğrulama mekanizmalarına odaklansa da, çoğu zaman gözden kaçırılan ancak son derece etkili bir savunma katmanı daha bulunmaktadır: HTTP Güvenlik Başlıkları. Bu başlıklar, tarayıcılar ve web sunucuları arasındaki iletişimi güçlendirerek, yaygın saldırı türlerine karşı proaktif bir koruma sağlarlar. Yanlış yapılandırılmış veya eksik HTTP başlıkları, sitenizi XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), Clickjacking ve MIME sniffing gibi çeşitli saldırılara karşı savunmasız bırakabilir. Bu kapsamlı rehberde, web uygulamalarınızı daha güvenli hale getirmek için kullanabileceğiniz başlıca HTTP güvenlik başlıklarını, bunların nasıl çalıştığını ve uygulamalarını detaylı bir şekilde inceleyeceğiz.
Web güvenlik mimarinizin temel taşlarından biri olarak kabul edilen HTTP başlıkları, kullanıcı deneyimini etkilemeden ek bir güvenlik bariyeri sunar. Bu başlıklar sayesinde, tarayıcılara belirli davranışları zorunlu kılabilir, potansiyel güvenlik açıklarını kapatabilir ve saldırganların istismar edebileceği zayıf noktaları azaltabilirsiniz. Unutmayın ki güvenlik sürekli bir süreçtir ve HTTP başlıklarının doğru yapılandırılması, bu sürecin önemli bir parçasıdır.
1. Strict-Transport-Security (HSTS): HTTPS'e Zorunlu Geçiş
Strict-Transport-Security (HSTS), web sitelerinin sadece HTTPS üzerinden erişilebilir olmasını zorunlu kılan kritik bir güvenlik başlığıdır. Bu başlık, bir tarayıcıya belirli bir siteye gelecekteki tüm erişim denemelerinin otomatik olarak HTTPS üzerinden yapılması gerektiğini bildirir. Bu, özellikle kullanıcının bir siteye ilk kez eriştiğinde veya siteye HTTP üzerinden yanlışlıkla bağlanmaya çalıştığında ortaya çıkabilecek Man-in-the-Middle (MITM) saldırılarını engellemek için hayati öneme sahiptir. HSTS olmadan, bir saldırgan ilk HTTP bağlantısını ele geçirerek kullanıcıyı sahte bir siteye yönlendirebilir veya hassas bilgileri çalabilir.
Örnek Yapılandırma:
* max-age: Tarayıcının siteyi HTTPS olarak hatırlayacağı saniye cinsinden süreyi belirtir. Genellikle bir yıl (31536000 saniye) olarak ayarlanır.
* includeSubDomains: Bu direktif, HSTS politikasının tüm alt alan adları için de geçerli olmasını sağlar.
* preload: Bu opsiyonel direktif, sitenizin HSTS preload listesine eklenmesi için başvuruda bulunmanızı sağlar. Bu listeye eklenen siteler, tarayıcılar tarafından varsayılan olarak HTTPS üzerinden yüklenir, yani daha ilk bağlantıdan itibaren MITM riski ortadan kalkar. HSTS preload hakkında daha fazla bilgi için hstspreload.org adresini ziyaret edebilirsiniz.
2. Content-Security-Policy (CSP): XSS ve Veri Enjeksiyonuna Karşı Kapsamlı Savunma
Content-Security-Policy (CSP), modern web güvenlik başlıklarının en güçlü ve esnek olanlarından biridir. Temel amacı, XSS (Cross-Site Scripting) ve diğer veri enjeksiyon saldırılarını önemli ölçüde azaltmaktır. CSP, tarayıcılara web sayfasının hangi kaynaklardan (scriptler, stiller, görseller, medya vb.) içerik yükleyebileceğini belirten katı kurallar koyarak çalışır. Bu sayede, kötü niyetli bir saldırganın zararlı kod enjekte etmesi durumunda bile, tarayıcı bu kodu çalışmayı reddederek saldırıyı etkisiz hale getirir.
CSP, karmaşık bir yapıda olabilir ve doğru şekilde yapılandırılması dikkat gerektirir. Yanlış bir CSP, sitenizin bazı özelliklerinin çalışmasını engelleyebilir.
Örnek Yapılandırma:
Bu örnekte:
* `default-src 'self'`: Tüm kaynaklar için varsayılan olarak yalnızca aynı kaynaktan yüklemeye izin verilir.
* `script-src 'self' https://cdnjs.cloudflare.com`: JavaScript kodları yalnızca kendi sunucumuzdan veya Cloudflare CDN'den yüklenebilir.
* `style-src 'self' 'unsafe-inline'`: CSS stilleri kendi sunucumuzdan veya doğrudan HTML içinde ('unsafe-inline') kullanılabilir. 'unsafe-inline' kullanmaktan kaçınmak en iyi uygulamadır, ancak bazı durumlarda geçici olarak gerekebilir.
* `img-src 'self' data:`: Görseller kendi sunucumuzdan veya base64 kodlu ('data:') olarak yüklenebilir.
* `frame-ancestors 'self'`: Sayfanın yalnızca aynı kökenden olan çerçeveler içinde gömülmesine izin verir.
* `form-action 'self'`: Form gönderimleri yalnızca aynı kökenden URL'lere yapılabilir.
* `report-to default`: İhlallerin belirlenen raporlama endpoint'ine gönderilmesini sağlar. Raporlama genellikle `Report-To` başlığı ile birlikte yapılandırılır.
3. X-Content-Type-Options: MIME Sniffing Saldırılarını Engelleme
X-Content-Type-Options, tarayıcıların dosya türlerini (MIME türleri) tahmin etme (sniffing) özelliğini devre dışı bırakan basit ama etkili bir güvenlik başlığıdır. MIME sniffing, tarayıcıların sunucunun bildirdiği Content-Type başlığını göz ardı ederek içeriği analiz edip kendi dosya türü tahminlerini yapmasına olanak tanır. Bu durum, bir saldırganın sitenize bir komut dosyası (örneğin, bir JavaScript dosyası) gibi yorumlanabilecek ancak aslında bir görsel veya metin dosyası olarak sunulan kötü amaçlı bir dosya yüklemesi durumunda tehlikeli olabilir. Tarayıcı bu dosyayı yanlışlıkla bir komut dosyası olarak yorumlarsa, XSS saldırısı riski doğar.
Örnek Yapılandırma:
* nosniff: Bu tek direktif, tarayıcıya sunucunun belirttiği Content-Type başlığına tam olarak güvenmesini ve MIME sniffing yapmamasını söyler. Eğer sunucu `text/css` olduğunu belirtirse, tarayıcı onu bir CSS dosyası olarak işler ve başka bir şey olarak yorumlamaya çalışmaz. Bu, özellikle kullanıcı tarafından yüklenen içeriklerin bulunduğu web uygulamaları için kritik öneme sahiptir.
4. X-Frame-Options: Clickjacking Koruması
X-Frame-Options başlığı, web sayfanızın `<iframe>`, `<frame>`, `<embed>` veya `<object>` etiketleri içinde başka siteler tarafından yüklenmesini (gömülmesini) kontrol ederek Clickjacking saldırılarını önlemeye yardımcı olur. Clickjacking, bir saldırganın şeffaf bir çerçeve kullanarak kendi kötü amaçlı sayfasının üzerine sitenizi bindirdiği ve kullanıcıları farkında olmadan saldırganın sitesindeki bir öğeye tıklattığı bir tekniktir.
Örnek Yapılandırma:
5. X-XSS-Protection: Eski Nesil XSS Koruması
X-XSS-Protection, tarayıcılarda yerleşik bir Cross-Site Scripting (XSS) filtresini etkinleştiren bir başlıktır. Bu başlık, tarayıcının olası XSS saldırılarını tespit etmeye ve engellemeye çalışmasını sağlar. Ancak, bu başlık modern web güvenlik uygulamalarında çoğu zaman gereksiz görülür ve hatta bazen kendisi güvenlik sorunlarına yol açabilir.
Örnek Yapılandırma:
* 0: XSS filtresini devre dışı bırakır.
* 1: XSS filtresini etkinleştirir. Tarayıcı bir XSS saldırısı algılarsa, sayfadaki şüpheli betik bölümlerini temizler.
* 1; mode=block: XSS filtresini etkinleştirir ve bir saldırı algılandığında sayfanın yüklenmesini tamamen engeller.
6. Referrer-Policy: Referer Bilgisini Kontrol Etme
Referrer-Policy başlığı, tarayıcının bir web sitesinden başka bir web sitesine bağlantı verirken Referer (yönlendiren) başlığını nasıl göndereceğini belirlemenizi sağlar. Referer başlığı, bir kullanıcının nereden geldiğini belirtir ve hassas bilgileri (örneğin, bir URL'deki sorgu parametreleri) içerebilir. Bu bilgilerin yanlış ellere geçmesi gizlilik ihlallerine yol açabilir.
Örnek Yapılandırma:
7. Permissions-Policy (Eski Adı: Feature-Policy): Tarayıcı Özelliklerini Kontrol Etme
Permissions-Policy (önceden Feature-Policy olarak biliniyordu), web geliştiricilerine tarayıcıdaki belirli API'leri ve web özelliklerini bir site veya gömülü iframe'ler için etkinleştirme veya devre dışı bırakma yeteneği verir. Bu, özellikle kötü amaçlı içeriklerin veya üçüncü taraf komut dosyalarının kullanıcı gizliliğini veya güvenliğini istismar etmesini önlemek için güçlü bir araçtır. Örneğin, bir web uygulamasının mikrofon veya kamera erişimine ihtiyacı yoksa, bu başlık ile bu erişimleri tamamen devre dışı bırakabilirsiniz.
Örnek Yapılandırma:
Bu örnekte:
* `geolocation=(self "https://example.com")`: Konum bilgisi (geolocation) API'sine yalnızca aynı kökenden (self) ve `https://example.com` adresinden gelen kaynaklar erişebilir.
* `microphone=()`: Mikrofon API'sine hiçbir kaynak erişemez (boş parantezler tüm erişimi engeller).
Sonuç: Kapsamlı Güvenlik İçin Entegre Yaklaşım
Web uygulamalarınızın güvenliği, tek bir çözümle değil, çok katmanlı ve entegre bir yaklaşımla sağlanır. HTTP güvenlik başlıkları, bu yaklaşımın vazgeçilmez bir parçasıdır. Her bir başlık, belirli bir tür saldırıya karşı özel bir savunma mekanizması sunar ve bunların bir araya getirilmesi, web sitenizin genel güvenlik duruşunu önemli ölçüde güçlendirir.
Unutulmamalıdır ki, bu başlıkların doğru ve etkili bir şekilde yapılandırılması, sürekli dikkat ve test gerektirir. Yeni güvenlik açıklarının keşfedilmesiyle birlikte tarayıcılar ve web standartları da gelişmeye devam etmektedir. Bu nedenle, güvenlik başlıklarınızı düzenli olarak gözden geçirmeli, güncel en iyi uygulamaları takip etmeli ve potansiyel güvenlik raporlarını izlemelisiniz.
Web sitenizi ve kullanıcılarınızı korumak için HTTP güvenlik başlıklarını etkin bir şekilde kullanarak, siber tehditlere karşı daha dirençli ve güvenilir bir çevrimiçi deneyim sunabilirsiniz.
Günümüzün sürekli gelişen siber tehdit ortamında, web uygulamalarının güvenliğini sağlamak her zamankinden daha kritik bir hale gelmiştir. Birçok geliştirici ve güvenlik uzmanı genellikle sunucu tarafı kod güvenliğine, veritabanı korumasına ve kimlik doğrulama mekanizmalarına odaklansa da, çoğu zaman gözden kaçırılan ancak son derece etkili bir savunma katmanı daha bulunmaktadır: HTTP Güvenlik Başlıkları. Bu başlıklar, tarayıcılar ve web sunucuları arasındaki iletişimi güçlendirerek, yaygın saldırı türlerine karşı proaktif bir koruma sağlarlar. Yanlış yapılandırılmış veya eksik HTTP başlıkları, sitenizi XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), Clickjacking ve MIME sniffing gibi çeşitli saldırılara karşı savunmasız bırakabilir. Bu kapsamlı rehberde, web uygulamalarınızı daha güvenli hale getirmek için kullanabileceğiniz başlıca HTTP güvenlik başlıklarını, bunların nasıl çalıştığını ve uygulamalarını detaylı bir şekilde inceleyeceğiz.
Web güvenlik mimarinizin temel taşlarından biri olarak kabul edilen HTTP başlıkları, kullanıcı deneyimini etkilemeden ek bir güvenlik bariyeri sunar. Bu başlıklar sayesinde, tarayıcılara belirli davranışları zorunlu kılabilir, potansiyel güvenlik açıklarını kapatabilir ve saldırganların istismar edebileceği zayıf noktaları azaltabilirsiniz. Unutmayın ki güvenlik sürekli bir süreçtir ve HTTP başlıklarının doğru yapılandırılması, bu sürecin önemli bir parçasıdır.
1. Strict-Transport-Security (HSTS): HTTPS'e Zorunlu Geçiş
Strict-Transport-Security (HSTS), web sitelerinin sadece HTTPS üzerinden erişilebilir olmasını zorunlu kılan kritik bir güvenlik başlığıdır. Bu başlık, bir tarayıcıya belirli bir siteye gelecekteki tüm erişim denemelerinin otomatik olarak HTTPS üzerinden yapılması gerektiğini bildirir. Bu, özellikle kullanıcının bir siteye ilk kez eriştiğinde veya siteye HTTP üzerinden yanlışlıkla bağlanmaya çalıştığında ortaya çıkabilecek Man-in-the-Middle (MITM) saldırılarını engellemek için hayati öneme sahiptir. HSTS olmadan, bir saldırgan ilk HTTP bağlantısını ele geçirerek kullanıcıyı sahte bir siteye yönlendirebilir veya hassas bilgileri çalabilir.
- Nasıl Çalışır: Sunucu, tarayıcıya bir HSTS başlığı gönderdiğinde, tarayıcı siteyi belirli bir süre (max-age değeri ile belirlenir) boyunca sadece HTTPS üzerinden yüklemek üzere hatırlar.
- Faydaları:
* MITM saldırılarını önler.
* HTTPS bağlantılarının güvenliğini artırır.
* Kullanıcıların her zaman şifreli bir bağlantı üzerinden siteye erişmesini sağlar.
* Performans artışı sağlayabilir (tarayıcının HTTP'den HTTPS'e yönlendirme yapmasına gerek kalmaz).
Örnek Yapılandırma:
Kod:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
* max-age: Tarayıcının siteyi HTTPS olarak hatırlayacağı saniye cinsinden süreyi belirtir. Genellikle bir yıl (31536000 saniye) olarak ayarlanır.
* includeSubDomains: Bu direktif, HSTS politikasının tüm alt alan adları için de geçerli olmasını sağlar.
* preload: Bu opsiyonel direktif, sitenizin HSTS preload listesine eklenmesi için başvuruda bulunmanızı sağlar. Bu listeye eklenen siteler, tarayıcılar tarafından varsayılan olarak HTTPS üzerinden yüklenir, yani daha ilk bağlantıdan itibaren MITM riski ortadan kalkar. HSTS preload hakkında daha fazla bilgi için hstspreload.org adresini ziyaret edebilirsiniz.
Önemli Not: HSTS'i etkinleştirmeden önce tüm sitenizin ve alt alan adlarınızın tamamen HTTPS üzerinden erişilebilir olduğundan emin olun. Aksi takdirde, sitenizin bazı bölümlerine erişilemez hale gelebilir.
2. Content-Security-Policy (CSP): XSS ve Veri Enjeksiyonuna Karşı Kapsamlı Savunma
Content-Security-Policy (CSP), modern web güvenlik başlıklarının en güçlü ve esnek olanlarından biridir. Temel amacı, XSS (Cross-Site Scripting) ve diğer veri enjeksiyon saldırılarını önemli ölçüde azaltmaktır. CSP, tarayıcılara web sayfasının hangi kaynaklardan (scriptler, stiller, görseller, medya vb.) içerik yükleyebileceğini belirten katı kurallar koyarak çalışır. Bu sayede, kötü niyetli bir saldırganın zararlı kod enjekte etmesi durumunda bile, tarayıcı bu kodu çalışmayı reddederek saldırıyı etkisiz hale getirir.
CSP, karmaşık bir yapıda olabilir ve doğru şekilde yapılandırılması dikkat gerektirir. Yanlış bir CSP, sitenizin bazı özelliklerinin çalışmasını engelleyebilir.
- Nasıl Çalışır: CSP başlığı, tarayıcıya farklı içerik türleri için izin verilen kaynakları tanımlayan bir dizi direktif içerir. Örneğin,
Kod:
script-src 'self' https://cdn.example.com;
- Temel Direktifler:
* default-src: Tüm içerik türleri için varsayılan politikayı ayarlar. Diğer direktifler belirtilmediğinde bu kullanılır.
* script-src: JavaScript kaynakları için geçerlidir.
* style-src: CSS stilleri için geçerlidir.
* img-src: Görsel kaynakları için geçerlidir.
* connect-src: XMLHttpRequest, WebSockets, EventSource gibi bağlantılar için geçerlidir.
* frame-src: `<iframe>`, `<frame>`, `<object>`, `<embed>` gibi gömülü içerikler için geçerlidir.
* font-src: Fontlar için geçerlidir.
* object-src: Flash veya diğer eklenti kaynakları için geçerlidir (genellikle 'none' olarak ayarlanır).
* base-uri: Sayfadaki `<base>` etiketi için geçerlidir.
* form-action: Form gönderme hedefleri için geçerlidir.
* frame-ancestors: Sayfanın hangi üst çerçeveler tarafından gömülebileceğini kontrol eder (Clickjacking önleme için X-Frame-Options'ın modern alternatifi).
* report-uri (eski) / report-to (yeni): Politika ihlallerinin bildirileceği URL'i belirtir.
Örnek Yapılandırma:
Kod:
Content-Security-Policy: default-src 'self';
script-src 'self' https://cdnjs.cloudflare.com;
style-src 'self' 'unsafe-inline';
img-src 'self' data:;
frame-ancestors 'self';
form-action 'self';
report-to default;
Bu örnekte:
* `default-src 'self'`: Tüm kaynaklar için varsayılan olarak yalnızca aynı kaynaktan yüklemeye izin verilir.
* `script-src 'self' https://cdnjs.cloudflare.com`: JavaScript kodları yalnızca kendi sunucumuzdan veya Cloudflare CDN'den yüklenebilir.
* `style-src 'self' 'unsafe-inline'`: CSS stilleri kendi sunucumuzdan veya doğrudan HTML içinde ('unsafe-inline') kullanılabilir. 'unsafe-inline' kullanmaktan kaçınmak en iyi uygulamadır, ancak bazı durumlarda geçici olarak gerekebilir.
* `img-src 'self' data:`: Görseller kendi sunucumuzdan veya base64 kodlu ('data:') olarak yüklenebilir.
* `frame-ancestors 'self'`: Sayfanın yalnızca aynı kökenden olan çerçeveler içinde gömülmesine izin verir.
* `form-action 'self'`: Form gönderimleri yalnızca aynı kökenden URL'lere yapılabilir.
* `report-to default`: İhlallerin belirlenen raporlama endpoint'ine gönderilmesini sağlar. Raporlama genellikle `Report-To` başlığı ile birlikte yapılandırılır.
CSP Geliştirme İpuçları: CSP'yi ilk kez uygularken `Content-Security-Policy-Report-Only` başlığını kullanarak politikayı uygulayın. Bu, tarayıcının politikayı ihlal eden durumları raporlamasına rağmen engellememesini sağlar. Böylece üretim ortamınızı etkilemeden hataları tespit edebilirsiniz. MDN Web Docs üzerinde CSP hakkında daha detaylı bilgi bulabilirsiniz.
3. X-Content-Type-Options: MIME Sniffing Saldırılarını Engelleme
X-Content-Type-Options, tarayıcıların dosya türlerini (MIME türleri) tahmin etme (sniffing) özelliğini devre dışı bırakan basit ama etkili bir güvenlik başlığıdır. MIME sniffing, tarayıcıların sunucunun bildirdiği Content-Type başlığını göz ardı ederek içeriği analiz edip kendi dosya türü tahminlerini yapmasına olanak tanır. Bu durum, bir saldırganın sitenize bir komut dosyası (örneğin, bir JavaScript dosyası) gibi yorumlanabilecek ancak aslında bir görsel veya metin dosyası olarak sunulan kötü amaçlı bir dosya yüklemesi durumunda tehlikeli olabilir. Tarayıcı bu dosyayı yanlışlıkla bir komut dosyası olarak yorumlarsa, XSS saldırısı riski doğar.
Örnek Yapılandırma:
Kod:
X-Content-Type-Options: nosniff
* nosniff: Bu tek direktif, tarayıcıya sunucunun belirttiği Content-Type başlığına tam olarak güvenmesini ve MIME sniffing yapmamasını söyler. Eğer sunucu `text/css` olduğunu belirtirse, tarayıcı onu bir CSS dosyası olarak işler ve başka bir şey olarak yorumlamaya çalışmaz. Bu, özellikle kullanıcı tarafından yüklenen içeriklerin bulunduğu web uygulamaları için kritik öneme sahiptir.
4. X-Frame-Options: Clickjacking Koruması
X-Frame-Options başlığı, web sayfanızın `<iframe>`, `<frame>`, `<embed>` veya `<object>` etiketleri içinde başka siteler tarafından yüklenmesini (gömülmesini) kontrol ederek Clickjacking saldırılarını önlemeye yardımcı olur. Clickjacking, bir saldırganın şeffaf bir çerçeve kullanarak kendi kötü amaçlı sayfasının üzerine sitenizi bindirdiği ve kullanıcıları farkında olmadan saldırganın sitesindeki bir öğeye tıklattığı bir tekniktir.
Örnek Yapılandırma:
Kod:
X-Frame-Options: DENY
- DENY: Sayfanın hiçbir çerçeve içinde gösterilmesine izin vermez. Bu en güvenli seçenektir.
- SAMEORIGIN: Sayfanın yalnızca aynı kökenden (domain, protokol ve port) bir sayfa içinde çerçevelenebilmesine izin verir.
- ALLOW-FROM uri (deprecate edildi): Belirli bir URI'dan geliyorsa çerçevelemeye izin verir. Ancak bu direktif modern tarayıcılarda desteklenmemektedir ve Content-Security-Policy'nin `frame-ancestors` direktifi ile değiştirilmiştir.
Modern Yaklaşım: `X-Frame-Options` hala yaygın olarak kullanılsa da, CSP'nin `frame-ancestors` direktifi, Clickjacking koruması için daha esnek ve geleceğe yönelik bir çözümdür. Mümkünse CSP'yi tercih edin.
5. X-XSS-Protection: Eski Nesil XSS Koruması
X-XSS-Protection, tarayıcılarda yerleşik bir Cross-Site Scripting (XSS) filtresini etkinleştiren bir başlıktır. Bu başlık, tarayıcının olası XSS saldırılarını tespit etmeye ve engellemeye çalışmasını sağlar. Ancak, bu başlık modern web güvenlik uygulamalarında çoğu zaman gereksiz görülür ve hatta bazen kendisi güvenlik sorunlarına yol açabilir.
Örnek Yapılandırma:
Kod:
X-XSS-Protection: 1; mode=block
* 0: XSS filtresini devre dışı bırakır.
* 1: XSS filtresini etkinleştirir. Tarayıcı bir XSS saldırısı algılarsa, sayfadaki şüpheli betik bölümlerini temizler.
* 1; mode=block: XSS filtresini etkinleştirir ve bir saldırı algılandığında sayfanın yüklenmesini tamamen engeller.
Önemli Not: `X-XSS-Protection` başlığı, Content-Security-Policy'nin (CSP) yaygınlaşmasıyla birlikte büyük ölçüde kullanım dışı kalmıştır. CSP, XSS'e karşı çok daha kapsamlı ve güvenli bir koruma sağladığı için, bu başlığın kullanımı genellikle önerilmez ve bazı durumlarda tarayıcıda XSS filtrelerinin atlatılmasına yol açabilecek zayıflıkları ortaya çıkarabilir. Mümkün olduğunca CSP'ye odaklanmalısınız.
6. Referrer-Policy: Referer Bilgisini Kontrol Etme
Referrer-Policy başlığı, tarayıcının bir web sitesinden başka bir web sitesine bağlantı verirken Referer (yönlendiren) başlığını nasıl göndereceğini belirlemenizi sağlar. Referer başlığı, bir kullanıcının nereden geldiğini belirtir ve hassas bilgileri (örneğin, bir URL'deki sorgu parametreleri) içerebilir. Bu bilgilerin yanlış ellere geçmesi gizlilik ihlallerine yol açabilir.
Örnek Yapılandırma:
Kod:
Referrer-Policy: no-referrer-when-downgrade
- no-referrer: Tüm Referer başlıklarını tamamen engeller. Hiçbir köken bilgisi gönderilmez. En gizli seçenektir.
- no-referrer-when-downgrade: HTTPS'den HTTP'ye geçişlerde Referer başlığını göndermez. Diğer durumlarda (HTTPS'den HTTPS'e veya HTTP'den HTTP'ye) gönderir. Çoğu web sitesi için iyi bir varsayılan seçenektir.
- origin: Yalnızca kökeni (protokol, host, port) gönderir, tam URL'yi değil.
- origin-when-cross-origin: Aynı kökene yapılan isteklerde tam URL'yi gönderir, farklı kökenlere yapılan isteklerde sadece kökeni gönderir.
- same-origin: Yalnızca aynı kökenden yapılan isteklere tam Referer başlığını gönderir. Farklı kökenlere asla göndermez.
- strict-origin: HTTPS'den HTTPS'e isteklerde sadece kökeni gönderir, diğer durumlarda göndermez.
- strict-origin-when-cross-origin: HTTPS'den HTTPS'e isteklerde tam URL'yi gönderir, HTTPS'den HTTP'ye isteklerde kökeni gönderir, diğer durumlarda göndermez.
- unsafe-url: Her zaman tam URL'yi gönderir. En az güvenli seçenektir ve genellikle tavsiye edilmez.
Gizlilik ve Analiz Dengesi: `Referrer-Policy` seçimi, gizlilik endişeleri ile web analizi ihtiyaçları arasında bir denge kurulmasını gerektirir. `no-referrer-when-downgrade` veya `same-origin` genellikle iyi bir başlangıç noktasıdır. Daha detaylı bilgi için MDN Referrer-Policy dokümanına bakabilirsiniz.
7. Permissions-Policy (Eski Adı: Feature-Policy): Tarayıcı Özelliklerini Kontrol Etme
Permissions-Policy (önceden Feature-Policy olarak biliniyordu), web geliştiricilerine tarayıcıdaki belirli API'leri ve web özelliklerini bir site veya gömülü iframe'ler için etkinleştirme veya devre dışı bırakma yeteneği verir. Bu, özellikle kötü amaçlı içeriklerin veya üçüncü taraf komut dosyalarının kullanıcı gizliliğini veya güvenliğini istismar etmesini önlemek için güçlü bir araçtır. Örneğin, bir web uygulamasının mikrofon veya kamera erişimine ihtiyacı yoksa, bu başlık ile bu erişimleri tamamen devre dışı bırakabilirsiniz.
Örnek Yapılandırma:
Kod:
Permissions-Policy: geolocation=(self "https://example.com"), microphone=()
Bu örnekte:
* `geolocation=(self "https://example.com")`: Konum bilgisi (geolocation) API'sine yalnızca aynı kökenden (self) ve `https://example.com` adresinden gelen kaynaklar erişebilir.
* `microphone=()`: Mikrofon API'sine hiçbir kaynak erişemez (boş parantezler tüm erişimi engeller).
- Nasıl Çalışır: Her bir direktif, belirli bir tarayıcı özelliğini ve bu özelliğe kimin erişebileceğini belirtir.
* 'self': Aynı kökenden gelen kaynaklara izin verir.
* '*': Tüm kaynaklara izin verir (genellikle kaçınılmalıdır).
* 'none': Hiçbir kaynağa izin vermez.
* URI listesi: Belirli domainlere izin verir.
Geleceğe Yönelik Güvenlik: Permissions-Policy, modern web uygulamaları için giderek daha önemli hale gelen bir başlıktır. Sitenizin yalnızca gerçekten ihtiyaç duyduğu tarayıcı özelliklerini kullanmasını sağlayarak saldırı yüzeyinizi önemli ölçüde azaltır. Mevcut özellik listesi ve kullanımları için MDN Permissions-Policy dokümanını inceleyebilirsiniz.
Sonuç: Kapsamlı Güvenlik İçin Entegre Yaklaşım
Web uygulamalarınızın güvenliği, tek bir çözümle değil, çok katmanlı ve entegre bir yaklaşımla sağlanır. HTTP güvenlik başlıkları, bu yaklaşımın vazgeçilmez bir parçasıdır. Her bir başlık, belirli bir tür saldırıya karşı özel bir savunma mekanizması sunar ve bunların bir araya getirilmesi, web sitenizin genel güvenlik duruşunu önemli ölçüde güçlendirir.
Unutulmamalıdır ki, bu başlıkların doğru ve etkili bir şekilde yapılandırılması, sürekli dikkat ve test gerektirir. Yeni güvenlik açıklarının keşfedilmesiyle birlikte tarayıcılar ve web standartları da gelişmeye devam etmektedir. Bu nedenle, güvenlik başlıklarınızı düzenli olarak gözden geçirmeli, güncel en iyi uygulamaları takip etmeli ve potansiyel güvenlik raporlarını izlemelisiniz.
Tavsiye: Başlıkları aşamalı olarak uygulayın ve her değişiklikten sonra sitenizi kapsamlı bir şekilde test edin. Özellikle Content-Security-Policy gibi karmaşık başlıkları önce "Report-Only" modunda uygulayarak olası sorunları üretim ortamını etkilemeden tespit edebilirsiniz. Güvenlik, bir ürün özelliği değil, bir süreçtir.
Web sitenizi ve kullanıcılarınızı korumak için HTTP güvenlik başlıklarını etkin bir şekilde kullanarak, siber tehditlere karşı daha dirençli ve güvenilir bir çevrimiçi deneyim sunabilirsiniz.