Security headers neden önemlidir?
HTTP yanıt başlıkları, tarayıcıya içeriğin nasıl ele alınacağı konusunda ek politikalar iletebilir. Güvenlik başlıkları tek başına bir web uygulamasını güvenli hale getirmez; ancak tarayıcı tarafındaki saldırı yüzeyini azaltmaya yardımcı olan önemli savunma katmanları oluşturabilir. Uygulamanın authentication, yetkilendirme, input validation ve sunucu güvenliği gibi temel kontrolleri yine ayrı konulardır.
Content-Security-Policy (CSP)
CSP, tarayıcının hangi kaynaklardan script, style, image, font veya frame yükleyebileceğini sınırlamak için kullanılan güçlü bir politikadır. En büyük faydası, uygulamanın beklenmeyen bir kaynaktan script çalıştırmasını zorlaştırmasıdır. Ancak CSPyi mevcut bir siteye doğrudan çok katı şekilde uygulamak üçüncü taraf ödeme, analytics, CDN veya inline scriptleri kırabilir.
Güvenli bir geçiş için önce raporlama yaklaşımıyla mevcut kaynakları gözlemlemek, sonra gereksiz kaynakları azaltmak ve politika kademeli olarak sıkılaştırmak daha kontrollüdür.
HSTS nedir?
Strict-Transport-Security başlığı, tarayıcının domain için HTTPS kullanmasını zorunlu hale getiren bir mekanizmadır. HTTPS altyapınız tüm kullanıcı yollarında sağlam değilse HSTS yanlış zamanda etkinleştirildiğinde erişim problemlerine yol açabilir. Bu yüzden önce sertifika, redirect ve alt domain kapsamını test etmek gerekir.
X-Content-Type-Options
Bu başlık genellikle nosniff değeriyle kullanılır ve tarayıcının bazı MIME türlerini tahmin ederek farklı şekilde yorumlamasını sınırlamaya yardımcı olur. Sunucunun doğru Content-Type döndürmesiyle birlikte düşünülmelidir.
X-Frame-Options ve frame-ancestors
Clickjacking riskini azaltmak için sayfanın başka bir origin tarafından iframe içine alınmasını sınırlamak gerekebilir. Modern CSP içindeki frame-ancestors daha esnek bir kontrol sunabilir. Eski ve yeni mekanizmaları projenizin tarayıcı desteği ve mimarisine göre birlikte değerlendirin.
Referrer-Policy ve Permissions-Policy
Referrer-Policy, bir sayfadan başka bir adrese giderken referer bilgisinin ne kadarının gönderileceğini kontrol eder. Permissions-Policy ise kamera, mikrofon, geolocation gibi tarayıcı özelliklerinin hangi originlerde kullanılabileceğini sınırlamak için tasarlanmıştır. Her iki başlık da gereksiz veri paylaşımını ve kullanılmayan özelliklerin yüzey alanını azaltmaya yardımcı olabilir.
Security headers nasıl kontrol edilir?
Security Headers ile bir sitenin HTTP yanıtındaki başlıkları hızlıca inceleyebilirsiniz. Ayrıntılı teşhis için HTTP Headers ile tüm yanıt başlıklarını görmek ve CDN/origin katmanlarının farklı header üretip üretmediğini kontrol etmek faydalıdır.
Yaygın hatalar
- CSPyi test etmeden doğrudan productiona almak.
- HSTSyi HTTP erişimi veya sertifika altyapısı hazır değilken etkinleştirmek.
- Headerları yalnızca CDN üzerinde ayarlayıp origin sunucunun farklı cevap vermesine izin vermek.
- Güvenlik headerlarını “var/yok” şeklinde değerlendirip uygulama açığını görmezden gelmek.
- Üçüncü taraf scriptleri sınırsız
*kaynaklarıyla izin verilen CSPye dönüştürmek.
Sonuç
Güvenlik headerları bir web uygulamasının savunma katmanlarından biridir. En iyi sonuç, mevcut uygulamanın gerçek kaynaklarını ve kullanıcı akışlarını analiz edip politikaları kademeli olarak sıkılaştırmakla elde edilir. Header kontrolünü SSL, HTTP durum kodları ve uygulama güvenliğiyle birlikte yürütün.
CSP neden ilk denemede siteyi bozabilir?
Mevcut bir web sitesi çok sayıda üçüncü taraf kaynağa, inline script veya dinamik style üretimine dayanabilir. CSPyi bir anda sıkılaştırmak bu kaynakları engelleyebilir. Bu nedenle kaynak envanteri çıkarmak, raporlama yaklaşımıyla gözlem yapmak ve politika değişikliklerini kademeli uygulamak daha güvenli bir geçiş yöntemidir.
Güvenlik headerlarında CDN ve origin farkı
Bir header CDN katmanında eklenirken origin farklı bir değer döndürebilir. Ayrıca cachelenmiş eski response headerları bir süre kullanıcıya sunulabilir. Sorun yaşandığında hem edge hem origin cevabını ayrı ayrı incelemek, headerın hangi katmanda üretildiğini belirlemek gerekir.
Header kontrolü uygulama güvenliğinin yerine geçmez
CSP veya HSTS kullanmak SQL injection, XSS, yetkilendirme açığı veya zayıf parola politikası gibi uygulama problemlerini otomatik olarak çözmez. Güvenlik headerlarını savunma derinliğinin bir katmanı olarak görün ve uygulama, sunucu, bağımlılık ve erişim kontrolleriyle birlikte değerlendirin.
Headerların cachelenmesi neden önemlidir?
Bir güvenlik headerı değiştirildiğinde CDN veya browser cache nedeniyle eski politika bir süre daha görülebilir. Özellikle CSP gibi davranışı doğrudan değiştiren politikalarda cache purge planı ve kontrollü rollout önemlidir. Değişiklikten sonra gerçek response headerlarını tekrar test edin.
Güvenlik başlıkları için minimum değil, uygun politika
“En çok headerı eklemek” iyi güvenlik stratejisi değildir. Kullanılmayan bir özelliği yanlış biçimde kısıtlamak uygulamayı bozabilir. Amaç projenin gerçek ihtiyaçlarına uygun, mümkün olduğunca dar ve sürdürülebilir politikalar oluşturmaktır.