Modern web sayfaları yalnızca kurumun kendi JavaScript kodundan oluşmaz. Ödeme sayfaları, analitik araçları, sohbet bileşenleri, A/B test sistemleri, reklam etiketleri ve ödeme SDK'ları gibi çok sayıda üçüncü taraf betik çalıştırabilir. Bu betiklerden biri ele geçirilirse, kullanıcı tarayıcısında çalışan zararlı kod WAAP'ın klasik request kontrolünü baypas edebilir.
Özellikle ödeme akışlarında istemci tarafı risk artık yalnızca iyi pratik konusu değildir. PCI DSS 4.0 v4.0.1 ile ödeme sayfalarında çalışan betiklerin kontrolü, envanteri ve bütünlüğü daha görünür hale gelmiştir. Kurumlar hangi sayfada hangi kaynağın çalışmasına izin verdiklerini göstermek zorundadır.
Uygulama ekiplerinin her sayfaya manuel CSP, HSTS, frame koruması veya referrer politikası eklemesi sürdürülebilir değildir. Legacy uygulamalarda kod değişikliği zordur; modern uygulamalarda ise farklı servis ekipleri aynı güvenlik standardını tutarlı uygulamayabilir. Sonuçta güvenlik başlıkları bazı sayfalarda vardır, bazılarında eksik kalır.
Doğru yaklaşım, tarayıcı güvenlik başlıklarını uygulama kodundan bağımsız, merkezi ve policy tabanlı şekilde uygulamaktır. ADC yanıt başlıklarını yeniden yazarak CSP, HSTS, clickjacking koruması, MIME sniffing önlemi, referrer kontrolü ve fingerprint temizliğini standart hale getirmelidir.
TR7 İstemci Tarafı Betik Koruması bu modeli sunar: istemci tarafı riskleri için temel güvenlik başlıklarını vService seviyesinde uygular ve tarayıcı güvenliğini merkezi WAAP politikasına bağlar.
TR7, istemci tarafı betik korumasını yanıt başlığı yeniden yazımı, CSP profili, fingerprint temizleme ve uyumluluk görünürlüğüyle uygular.
TR7, HTTP response aşamasında güvenlik başlıklarını set-header veya add-header davranışıyla uygular. Uygulama kodu veya sertifika yapısı değiştirilmeden tarayıcı güvenlik kontrolleri devreye alınabilir.
Content-Security-Policy başlığı, izin verilen kaynak modelini tarayıcıya bildirir. TR7 mevcut durumda sabit `default-src 'self';` yaklaşımıyla temel CSP koruması sunar.
Server, X-Powered-By, X-AspNet-Version ve X-AspNetMvc-Version gibi başlıklar yanıttan temizlenebilir. Böylece saldırganın teknoloji envanteri çıkarması ve CVE eşleştirmesi zorlaşır.
securityHeaders kuralı aktif olan vService'ler compliance raporlarında kanıt olarak gösterilebilir. Bu, ödeme sayfası güvenliği ve istemci tarafı kontrol süreçlerinde denetim izini güçlendirir.
İstemci Tarafı Betik Koruması, 8 hazır güvenlik başlığını tek securityHeaders kuralı altında uygular.
TR7, securityHeaders kuralı üzerinden Content-Security-Policy başlığını ekleyebilir. Mevcut davranış `default-src 'self';` şeklinde temel güvenlik politikası üretir. Bu politika, tarayıcının yalnızca aynı origin kaynaklarını varsayılan olarak kabul etmesini hedefler. Daha karmaşık CSP ihtiyaçları için uygulama ve özel header kurgusu ayrıca planlanmalıdır.
Strict-Transport-Security başlığı TLS kullanılan bağlantılarda uygulanabilir. Bu başlık tarayıcıya ilgili domain için HTTPS kullanımını zorunlu tutmasını söyler. includeSubDomains ve preload gibi seçeneklerle daha sıkı güvenlik davranışı sağlanabilir. HSTS yalnızca TLS bağlamında uygulanarak HTTP-only host'larda yanlış politika üretilmesi önlenir.
X-Frame-Options başlığı SAMEORIGIN değeriyle uygulanabilir. Bu, sayfanın farklı origin'lerde iframe içine alınmasını sınırlar. Özellikle login, ödeme, yönetim paneli ve hassas işlem sayfalarında clickjacking riskini azaltmaya yardımcı olur. Kullanıcı arayüzü saldırılarına karşı düşük maliyetli temel koruma sağlar.
X-Content-Type-Options başlığı nosniff değeriyle eklenebilir. Tarayıcının içerik tipini tahmin ederek beklenmeyen biçimde çalıştırmasını engellemeye yardımcı olur. Bu kontrol, özellikle dosya yükleme, statik içerik ve yanlış content-type dönen legacy uygulamalar için değerlidir. MIME confusion kaynaklı istemci tarafı riskleri azaltılır.
Referrer-Policy başlığı no-referrer-when-downgrade varsayılanıyla uygulanabilir. Bu, HTTPS'ten HTTP'ye geçiş gibi durumlarda referrer bilgisinin sızmasını azaltır. Vatandaş, müşteri veya oturum parametresi içeren URL'lerde referrer davranışı önemlidir. Kurum, tarayıcının dış sitelere ne kadar kaynak URL bilgisi taşıyacağını merkezi olarak sınırlandırabilir.
Permission-Policy başlığı mikrofon, kamera, coğrafi konum veya benzeri tarayıcı yetkilerinin kullanımını sınırlandırmak için kullanılabilir. TR7 bu başlığı securityHeaders kuralı altında uygulayarak gereksiz tarayıcı yetki yüzeyini azaltır. Özellikle portal, ödeme ve yönetim ekranlarında sayfanın beklenmeyen API'lere erişmesi engellenebilir. Bu, istemci tarafı güvenliği yalnızca script kaynağıyla sınırlı bırakmaz.
X-XSS-Protection başlığı modern tarayıcılarda sınırlı etkiye sahip olsa da eski tarayıcı uyumluluğu için kullanılabilir. `1; mode=block` davranışı bazı legacy istemcilerde temel XSS filtreleme katmanını devreye alır. Bu başlık tek başına güvenlik garantisi değildir; CSP ve WAAP kontrolleriyle birlikte düşünülmelidir. Legacy kullanıcı tabanı olan kurumlar için düşük maliyetli ek katman sunar.
TR7, Server, X-Powered-By, X-AspNet-Version ve X-AspNetMvc-Version gibi başlıkları silebilir. Bu başlıklar uygulama sunucusu, framework veya runtime versiyonu hakkında ipucu verebilir. Saldırgan bu bilgileri CVE eşleştirmesi ve hedefli exploit denemeleri için kullanabilir. Fingerprint temizliği, görünür saldırı yüzeyini azaltan pratik bir sertleştirme adımıdır.
securityHeaders bir kural tipi olarak belirli vService, domain veya path koşullarına bağlanabilir. Ödeme sayfası daha sıkı, iç portal daha farklı veya legacy uygulama daha uyumlu bir başlık setiyle çalıştırılabilir. Bu, tek global başlık politikasının uygulamaları kırmasını önler. Operatör güvenlik başlıklarını servis bağlamına göre uygular.
TR7, istemci tarafı betik korumasının mevcut bölümünü response header katmanında uygular. Ek JavaScript ajanı, istemci SDK'sı veya ayrı reverse proxy gerekmez. Bu yaklaşım düşük gecikme ve yüksek uyumluluk sağlar. Mevcut gerçek yetenek güvenlik başlığı standardizasyonudur; runtime skimmer tespiti veya SRI otomatik enjeksiyon iddiası yapılmaz.
securityHeaders kuralı aktif olan vService'ler uyumluluk raporlarında gösterilebilir. Bu, ödeme sayfası güvenlik başlıklarının nerede uygulandığını denetçiyle paylaşmayı kolaylaştırır. PCI DSS 4.0 v4.0.1 kapsamındaki istemci tarafı güvenlik beklentileri için teknik kanıt üretimine destek verir. Raporlama, başlık politikasının yalnızca yapılandırıldığını değil, hangi servislerde aktif olduğunu görünür kılar.
Bot protection veya erişim engelleme gibi özel HTML sayfaları döndürüldüğünde güvenlik başlıkları aynı response hattında korunabilir. Bu, hata veya challenge sayfalarının ana uygulamadan daha zayıf güvenlik başlıklarıyla dönmesini engeller. Kullanıcıya sunulan her yanıtın aynı temel tarayıcı güvenlik standardına yaklaşması sağlanır. Özellikle login ve bot doğrulama akışlarında tutarlılık önemlidir.
İstemci tarafı betik koruması; response header sırası, HSTS koşulu, sabit CSP davranışı, securityHeaders rule tipi ve fingerprint temizliğiyle birlikte işletilir.
TR7, bazı başlıkları set-header ile override edebilir, bazılarını add-header ile ekleyebilir. Bu ayrım mevcut uygulama başlıklarının nasıl davranacağını belirler. Production'a geçmeden önce uygulamanın kendi başlıklarıyla TR7 başlıklarının çakışıp çakışmadığı test edilmelidir.
HSTS yalnızca TLS bağlantılarında uygulanmalıdır. TR7 bu başlığı ssl_fc koşuluyla ilişkilendirerek HTTP-only host'ların hatalı HSTS almasını önler. Yanlış HSTS politikası bazı domainlerde erişim sorunlarına yol açabileceği için dikkatli kullanılmalıdır.
Mevcut securityHeaders davranışında CSP açıldığında `default-src 'self';` başlığı üretilir. Ek özel direktif editörü bu sayfanın aktif yetenekleri içinde sunulmaz. Daha ayrıntılı CSP ihtiyaçları için özel header kuralı veya uygulama tarafı düzenleme planlanmalıdır.
securityHeaders bir WAAP imza skoru kuralı gibi çalışmaz. Daima uygulanması gereken response header sertleştirme kuralı olarak değerlendirilir. Bu nedenle saldırı skoru veya threshold sonucuna bağlı değildir.
Server, X-Powered-By, X-AspNet-Version ve X-AspNetMvc-Version başlıkları temizlenebilir. Bu başlıkların kaldırılması uygulama davranışını değiştirmez; yalnızca teknoloji bilgisinin dışarı görünmesini azaltır. Legacy uygulamalarda bu basit adım önemli bilgi sızıntısını azaltabilir.
CSP ve frame politikaları bazı uygulama bileşenlerini etkileyebilir. Özellikle inline script kullanan veya dış kaynaklardan içerik yükleyen sayfalarda önce test ortamında doğrulama yapılmalıdır. TR7'nin kural bazlı yaklaşımı, sıkı politikayı önce sınırlı path veya domain üzerinde denemeyi kolaylaştırır.
E-ticaret ekipleri checkout sayfalarında CSP, HSTS ve server fingerprint temizliğini vService seviyesinde açabilir. Bu yapı, PCI DSS 4.0 v4.0.1 istemci tarafı güvenlik kontrolleri için raporlanabilir teknik kanıt üretir.
Bankacılık portalları X-Frame-Options SAMEORIGIN ve Permission-Policy ile yetkisiz iframe kullanımını ve gereksiz tarayıcı API erişimlerini sınırlandırabilir. Login ve işlem sayfalarında istemci tarafı saldırı yüzeyi daraltılır.
Kamu uygulamaları hassas URL bilgisi taşıyan sayfalarda Referrer-Policy uygulayabilir. Böylece vatandaş oturumuna veya işlem bağlamına ait URL parçalarının dış sitelere taşınma riski azaltılır.
Eski .NET veya benzeri uygulamalarda Server, X-Powered-By ve framework versiyon başlıkları dışarı sızabilir. TR7 bu başlıkları temizleyerek saldırganın teknoloji envanteri çıkarmasını zorlaştırır.
SaaS sağlayıcıları her tenant vService'i için farklı securityHeaders kombinasyonu uygulayabilir. B2B tenant'larda uyumluluk ihtiyacına göre daha gevşek, B2C akışlarda daha sıkı başlık politikaları seçilebilir.
CSP, HSTS, clickjacking koruması ve server fingerprint temizliği — uygulama kodu değiştirmeden, tek policy üzerinden. Kendi servislerinizle canlı bir kurulumda gezdirelim.