Cloudflare'ın edge'de enjekte ettiği analytics beacon'u katı CSP yapılandırmalarını tetikliyor

Bir geliştirici, Cloudflare'ın Web Analytics özelliğinin ağı üzerinden sunulan sayfalara sessizce bir izleme scripti enjekte ettiğini ve katı bir Content-Security-Policy'nin bunu engellediğini keşfetti; ortaya çıkan konsol hatası ve Lighthouse cezası, site sahiplerini hiç seçmedikleri bir host'a izin vermeye itiyor.

dev.to'da yayımlanan ve aslen indiecore.net'te yayınlanan bir yazıya göre yazar, bir siteyi deploy ettikten sonra alışkanlıkla tarayıcı konsolunu açtığında bir CSP ihlali gördü: tarayıcı, beacon.min.js dosyasını static.cloudflareinsights.com adresinden yüklemeyi reddetti, çünkü script-src direktifi yalnızca 'self', 'unsafe-inline' ve 'inline-speculation-rules'a izin veriyordu. Script hiçbir şablonda, hiçbir build çıktısında ve hiçbir bağımlılıkta görünmüyordu; derlenmiş HTML üzerinde cloudflareinsights için yapılan bir grep araması sıfır sonuç döndürdü.

Script depoda değil, edge'de ekleniyor

Yazıda açıklandığı gibi, Cloudflare Web Analytics'in bir site eklendiğinde varsayılan olarak açık olan otomatik bir modu var. Beacon scriptini HTML yanıtlarına edge'de ekliyor; dolayısıyla ne origin sunucusunda ne de kod tabanında hiçbir zaman bulunmuyor.

Enjeksiyon istemciler açısından da seçici. curl ile yapılan istekler veya masaüstü tarayıcı User-Agent dizesiyle yapılan istekler scripti içermeyen yanıtlar döndürdü. Scripti yalnızca gerçek bir tarayıcı gezinmesi aldı — Lighthouse'un bunu işaretlemesinin ve yazarın terminal kontrollerinin temiz kalmasının nedeni bu. Artefakt production'da var, kaynak kodda yok ve bir sunucunun ne döndürdüğünü incelerken insanların ilk başvurduğu komut satırı aracıyla yeniden üretilemiyor.

Hiçbir şey izlenmedi

CSP amaçlandığı gibi çalıştı. Lighthouse ağ kaydı, engellenen isteği -1 durum kodu ve sıfır bayt transfer boyutuyla kaydetti; yani tarayıcı URL'yi script-src ile eşleştirdi, izin verilen bir kaynak bulamadı ve bağlantı açılmadan önce reddetti. Ziyaretçinin tarayıcısından hiçbir veri çıkmadı.

Yine de hatanın bir bedeli var. Konsola düşen hata, Lighthouse Best Practices kategorisini 100'den 92'ye düşürdü; yazar da konsoldaki kalıcı kırmızı satırların geliştiricileri konsoldaki kırmızı satırları görmezden gelmeye alıştırdığını savunuyor.

Bariz çözüm sitenin vaatleriyle çelişiyor

Hata mesajını arattığınızda öne çıkan tavsiye, Cloudflare insights host'unu script-src'ye eklemek. Bu konsolu susturur ve skoru yaklaşık on saniyede geri getirir. Ancak yazarın gizlilik politikası, tarayıcıda hiçbir türde analytics scriptinin çalışmadığını ve bir fragman başlatılmadıkça domain dışına hiçbir isteğin çıkmadığını belirtiyor. Host'a izin vermek, konsolu yeşile çeviren aynı düzenlemede bu cümleyi yalan haline getirirdi — ve build'de hiçbir şey itiraz etmezdi, çünkü politika bir metin, CSP bir başlık ve ikisini bağlayan hiçbir şey yok.

Politikayla tutarlı çözüm repository'de değil Cloudflare dashboard'unda: site için Web Analytics'i devre dışı bırakmak enjeksiyonu tamamen durduruyor; böylece konsol, script içeri davet edildiği için değil, yok olduğu için sessizleşiyor.

Politikayı başlıklara bağlayan bir build kontrolü

Vaadi zorunlu kılmak için yazar, gizlilik politikasını okuyan ve politika analytics olmadığını iddia ettiğinde headers dosyasındaki script-src ve connect-src direktiflerini inceleyip herhangi bir harici http veya https host'u ya da bir wildcard varsa build'i başarısız kılan bir build adımı ekledi. frame-src bilinçli olarak hariç tutuldu, çünkü sitenin YouTube fragman gömmesi politikada adı geçen tek belgelenmiş istisna. Yazar, kontrolü geçici olarak beacon host'unu ekleyip build'in başarısız olduğunu izleyerek doğruladı; gerekçesi şuydu: hiç başarısız olduğu görülmeyen bir kontrol gerçekten kontrol değildir.

Yerel CI bunu göremez

Yazarın CI pipeline'ı Lighthouse'ı yalnızca derlenmiş çıktıyı sunan yerel bir statik sunucuya karşı çalıştırıyor — CDN yok, edge özellikleri yok, enjeksiyon yok. Tüm denetimler 100 geçiyor, ama o bir dizini ölçüyor; production ise o dizin artı kendi davranışına sahip bir CDN. Yazar artık her deploy'dan sonra canlı host adına karşı bir ek denetim daha çalıştırıyor ve konsolu okuyor; zaten enjekte edilen scripti ilk ortaya çıkaran da buydu.

Bir konu hâlâ çözümsüz. Yanıt başlıkları ayrıca Network Error Logging'i yapılandırıyor ve raporlar bir Cloudflare endpoint'ine yönlendiriliyor. Hiçbir script çalışmıyor, dolayısıyla "tarayıcınızda analytics scripti çalışmaz" ifadesi geçerliliğini koruyor; ama başarısız bir istek Cloudflare'e bir rapor gönderecektir ve bu, domain dışına hiçbir şey çıkmaz şeklindeki politika iddiasıyla çelişki içinde duruyor. Başlıklar CSP'nin erişimi dışında, bu yüzden repository'deki hiçbir şey bunu engelleyemez.

Neden önemli

Bu, Web Analytics'in otomatik modunun açık olduğu Cloudflare arkasındaki her siteyi etkiliyor: sahipler, hiç yazmadıkları, hiç commit etmedikleri ve grep ile bulamayacakları bir üçüncü taraf scripti yayınlayabilirler. Katı bir CSP bunu engeller, ama görünür belirtiler — bir konsol hatası ve daha düşük bir Best Practices skoru — geliştiricileri scriptin nereden geldiğini sorgulamak yerine host'u allowlist'e eklemeye yönlendiriyor. Aynı zamanda edge computing hakkında daha geniş bir ders: CDN katmanında yapılan değişiklikler yerel build'ler, curl tabanlı doğrulama ve geleneksel CI için görünmezdir; dolayısıyla tek güvenilir kontrol, her sürümden sonra gerçek deploy edilmiş origin'i denetlemektir.