Üçüncü Taraf Scriptler ve JavaScript Tedarik Zinciri Güvenliği

Rehber · Tedarik zinciri

Modern web siteleri artık yalnızca kendi geliştiricilerinin yazdığı JavaScript kodlarından oluşmuyor.

Analytics araçları, reklam platformları, canlı destek sistemleri, ödeme servisleri, A/B test araçları, chatbotlar, sosyal medya entegrasyonları, tag manager’lar, CDN’ler ve çeşitli pazarlama araçları bir web sitesinin çalışması için onlarca farklı üçüncü taraf JavaScript dosyasının yüklenmesine neden olabiliyor.

Bu durum geliştirme süreçlerini hızlandırırken aynı zamanda önemli bir güvenlik problemi ortaya çıkarıyor:

Web sitenize eklediğiniz her üçüncü taraf script, aslında güvenlik sınırlarınızın bir kısmını başka bir sisteme emanet etmeniz anlamına gelir.

Üstelik risk yalnızca scriptin ilk eklendiği anda ortaya çıkmaz. Üçüncü taraf servis tarafında yapılan bir değişiklik, ele geçirilen bir CDN hesabı, güvenliği ihlal edilmiş bir npm paketi veya değiştirilmiş bir JavaScript dosyası, sizin uygulamanızda hiçbir kod değişikliği yapmadan yeni bir güvenlik açığı oluşturabilir.

Bu nedenle üçüncü taraf JavaScript kullanımı artık yalnızca bir performans veya frontend konusu değil, JavaScript tedarik zinciri güvenliği (JavaScript Supply Chain Security) konusu olarak değerlendirilmelidir.

JavaScript tedarik zinciri nedir?

Bir web uygulamasının kullandığı JavaScript kodlarını üç temel grupta düşünebiliriz:

1. Kendi geliştiricilerinizin yazdığı kodlar
2. Projenize eklediğiniz açık kaynak bağımlılıklar
3. Harici servislerden doğrudan yüklenen üçüncü taraf scriptler

Örneğin bir e-ticaret sitesinde aşağıdaki servislerin bulunduğunu düşünelim:

Web Site
│
├── Google Analytics
├── Google Tag Manager
├── Meta Pixel
├── Hotjar
├── Live Chat
├── Payment SDK
├── CAPTCHA
├── A/B Testing
└── Customer Support Widget

Bu servislerin her biri farklı bir organizasyon tarafından yönetilebilir.

Web sitenizin güvenliği açısından önemli olan nokta şudur:

Sitenizin güvenliği yalnızca kendi yazdığınız JavaScript kodunun güvenli olmasına bağlı değildir.

Kullandığınız üçüncü taraf kodlar da uygulamanızın saldırı yüzeyinin bir parçasıdır.

Üçüncü taraf script nedir?

Üçüncü taraf script, web sitenizin kendi sunucusunda veya uygulama kodunuzun içinde doğrudan yönetilmeyen ancak tarayıcıda çalıştırılan JavaScript kodudur.

Örneğin:

<script src="https://example-analytics.com/tracker.js"></script>

veya:

<script src="https://cdn.example.com/widget.js"></script>

gibi bir kullanım üçüncü taraf JavaScript yüklenmesine örnektir.

Bunun yanında Google Tag Manager gibi sistemler üzerinden dinamik olarak yüklenen scriptler de üçüncü taraf script kapsamına girebilir.

Bu sistemler oldukça kullanışlıdır. Ancak burada kritik bir nokta vardır:

Tarayıcıda çalışan JavaScript kodu, yalnızca “istatistik toplamak” gibi masum bir işlem yapmayabilir.

Kodun sahip olduğu yetkilere bağlı olarak DOM’a erişebilir, kullanıcı etkileşimlerini izleyebilir, ağ istekleri oluşturabilir ve bazı durumlarda sayfadaki hassas bilgileri okuyabilir.

Bu nedenle bir scriptin yalnızca “analytics”, “marketing” veya “support” amacıyla kullanılması tek başına güvenli olduğu anlamına gelmez.

Neden üçüncü taraf JavaScript bir güvenlik riskidir?

Bir web sitesine JavaScript eklediğinizde tarayıcı bu kodu sizin sitenizin bir parçasıymış gibi çalıştırabilir.

Örneğin:

<script src="https://third-party.example/script.js"></script>

Burada kullanıcı example.com adresini ziyaret ediyor olabilir. Ancak JavaScript kodu third-party.example üzerinden geliyor. Dolayısıyla web sitenizin çalışma ortamına dışarıdan bir kod dahil edilmiş oluyor.

Bu durum güvenlik açısından bir trust boundary oluşturur.

Kullanıcı
   ↓
Sizin Web Siteniz
   ↓
Üçüncü Taraf Script
   ↓
Harici Sistem

Üçüncü taraf sistemin güvenliği bozulursa sizin uygulamanız da bundan etkilenebilir.

JavaScript tedarik zinciri saldırısı nedir?

JavaScript supply chain attack, uygulamanın doğrudan kendi kodunu hedeflemek yerine uygulamanın güvendiği bir bağımlılığın, paketin, CDN’in veya üçüncü taraf script sağlayıcısının hedef alınmasıdır.

Saldırgan doğrudan sizin sunucunuza saldırmak yerine şu zincirin herhangi bir noktasını hedefleyebilir:

Developer
   ↓
npm package
   ↓
Build system
   ↓
CDN
   ↓
Third-party JavaScript
   ↓
Your Website
   ↓
User

Bu yaklaşım saldırgan açısından oldukça değerlidir. Çünkü bir üçüncü taraf sağlayıcıya erişim elde edildiğinde aynı scripti kullanan yüzlerce veya binlerce web sitesi etkilenebilir.

Bir scriptin sonradan değiştirilmesi neden önemlidir?

En önemli risklerden biri scriptin zaman içinde değişebilmesidir.

Örneğin bugün sitenizde:

<script src="https://cdn.example.com/widget.js"></script>

bulunuyor. Bugün bu dosya tamamen güvenli olabilir. Ancak yarın widget.js dosyası değiştirilebilir.

Bu değişiklik sizin Git repository’nizde görünmeyebilir. Deploy işlemi yapmanız gerekmez. Uygulamanızın kodunu değiştirmeniz gerekmez. Ancak kullanıcı ertesi gün sitenize girdiğinde tarayıcı yeni JavaScript dosyasını çalıştırabilir.

İşte JavaScript tedarik zinciri güvenliğinin temel problemlerinden biri budur.

CDN kullanmak güvenli olduğu anlamına gelmez

CDN’ler modern web uygulamalarında çok yaygın kullanılır.

<script src="https://cdn.example.com/library.min.js"></script>

Performans açısından oldukça mantıklı olabilir. Ancak güvenlik açısından şu soruların cevaplanması gerekir:

• Bu dosyanın içeriğini kim kontrol ediyor?
• Dosya değiştirilebilir mi?
• CDN hesabı nasıl korunuyor?
• Dosyanın bütünlüğü nasıl doğrulanıyor?
• Script hangi domainlerden yükleniyor?
• Scriptin kaynağı zaman içinde değişiyor mu?
• Script ne kadar yetkiye sahip?
• Script artık gerekli mi?

Buradaki temel problem şudur: URL’nin aynı kalması, dosyanın aynı kaldığı anlamına gelmez.

Subresource Integrity (SRI) nedir?

Üçüncü taraf JavaScript dosyalarının bütünlüğünü doğrulamak için kullanılabilecek mekanizmalardan biri Subresource Integrity (SRI)’dir.

<script
  src="https://cdn.example.com/library.js"
  integrity="sha384-..."
  crossorigin="anonymous">
</script>

Buradaki integrity değeri JavaScript dosyasının beklenen içeriğini temsil eden cryptographic hash bilgisidir. Tarayıcı dosyayı indirdiğinde içeriğin hash değerini kontrol eder. Dosya değiştirilmişse beklenen hash ile eşleşmez. Bu durumda tarayıcı scripti çalıştırmaz.

Beklenen dosya
      ↓
   SHA-384
      ↓
Beklenen hash

İndirilen dosya
      ↓
   SHA-384
      ↓
Gerçek hash
       ↓
Karşılaştır
       ↓
  Eşleşiyor?
   /       \
 Evet      Hayır
  ↓          ↓
Çalıştır    Engelle

SRI özellikle statik ve hash’i kontrol edilebilir üçüncü taraf kaynaklar için faydalıdır. Ancak her üçüncü taraf script için uygulanması kolay değildir. Özellikle script içeriğinin sağlayıcı tarafından dinamik olarak değiştirilmesi beklenen sistemlerde SRI operasyonel olarak sorun yaratabilir.

Bu nedenle SRI tek başına çözüm değildir.

Content Security Policy (CSP) neden önemlidir?

Üçüncü taraf JavaScript güvenliğinde bir diğer önemli mekanizma Content Security Policy (CSP)’dir.

Content-Security-Policy:
  script-src 'self' https://trusted.example.com;

Bu politika tarayıcıya hangi kaynaklardan JavaScript çalıştırılmasına izin verildiğini söyleyebilir. Böylece uygulamanız kendi domaininiz ve güvenilen üçüncü taraflarla sınırlandırılabilir.

CSP’nin güçlü tarafı yalnızca üçüncü taraf scriptleri kontrol etmek değildir. Aynı zamanda XSS gibi bazı saldırıların etkisini azaltmaya yardımcı olabilir.

Ancak CSP’nin yanlış yapılandırılması da güvenlik problemi yaratabilir. Örneğin script-src * gibi aşırı geniş bir politika gerçek anlamda güçlü bir kısıtlama sağlamaz. Bu nedenle CSP’nin varlığı kadar nasıl yapılandırıldığı da önemlidir.

Google Tag Manager neden ayrıca değerlendirilmelidir?

Tag management sistemleri pazarlama ve ürün ekipleri için oldukça kullanışlıdır. Örneğin geliştiriciye her seferinde deployment yaptırmadan analytics, conversion tracking, advertising pixels, A/B testing, heatmap ve marketing integrations eklenebilir.

Ancak bunun güvenlik açısından önemli bir sonucu vardır: kod üretim sisteminizden bağımsız olarak değişebilir.

Developer
    ↓
Tag Manager
    ↓
Multiple Scripts
    ↓
Browser

Bu nedenle Tag Manager hesabının erişim güvenliği, kullanıcı yetkileri ve eklenen tag’lerin düzenli olarak incelenmesi önemlidir.

npm bağımlılıkları da tedarik zincirinin parçasıdır

Risk yalnızca CDN üzerinden yüklenen JavaScript dosyalarından oluşmaz. Modern frontend projelerinde npm install package-name ile eklenen bağımlılıklar da JavaScript tedarik zincirinin önemli bir parçasıdır.

Your Application
       ↓
React / Angular / Vue
       ↓
Package A
       ↓
Package B
       ↓
Package C

Bir paketin doğrudan kötü amaçlı olması gerekmiyor. Bağımlılık ağacının daha aşağı seviyesindeki bir paket de risk oluşturabilir. Bu nedenle Direct Dependencies kadar Transitive Dependencies de önemlidir.

Bir npm paketinin ele geçirilmesi nasıl gerçekleşebilir?

Bir saldırganın hedefi doğrudan sizin uygulamanız olmayabilir.

Popüler Package
      ↓
Maintainer Account
      ↓
Package Registry
      ↓
Malicious Version
      ↓
Developers
      ↓
Production Applications

Saldırgan yeni bir paket sürümü yayınlayabilir. Bu sürüm CI/CD pipeline’ına dahil olabilir. Sonuç olarak kötü amaçlı kod üretim uygulamasına kadar ulaşabilir.

Bu yüzden dependency management yalnızca “paket güncel mi?” sorusundan ibaret değildir.

Typosquatting nedir?

Tedarik zinciri saldırılarında kullanılan yöntemlerden biri de typosquatting’dir. Saldırgan popüler bir paketin adına çok benzeyen sahte bir paket oluşturabilir.

Örneğin popular-package yerine popular_packge veya popular-package-js gibi bir isim kullanılabilir. Geliştirici yanlış paketi yüklediğinde kötü amaçlı kod uygulamaya dahil olabilir.

Bu nedenle yeni dependency eklemek basit bir npm install işlemi olarak görülmemelidir.

Üçüncü taraf scriptler kullanıcı verilerine erişebilir mi?

Bu sorunun cevabı scriptin çalıştığı bağlama ve sahip olduğu yetkilere bağlıdır. Tarayıcıda çalışan JavaScript DOM üzerinde çeşitli işlemler gerçekleştirebilir; örneğin document.querySelector(...) ile sayfadaki elementlere erişebilir.

Form alanları, kullanıcı etkileşimleri veya sayfadaki bazı bilgiler bu nedenle üçüncü taraf scriptler açısından önemli hale gelebilir. Özellikle şu alanlarda üçüncü taraf scriptlerin kullanımı daha dikkatli değerlendirilmelidir:

• Login sayfaları
• Checkout sayfaları
• Kullanıcı profilleri
• Ödeme ekranları
• Sağlık bilgileri içeren ekranlar
• Kurumsal paneller
• Kişisel veri içeren formlar

Burada yalnızca teknik güvenlik değil, veri gizliliği de devreye girer.

Üçüncü taraf scriptler KVKK açısından neden önemlidir?

Bir script kullanıcı davranışlarını veya kişisel verileri üçüncü taraf bir servise aktarıyorsa konu yalnızca frontend güvenliği olmaktan çıkar.

User
 ↓
Website
 ↓
Analytics Script
 ↓
Third-party service

Bu nedenle şirketlerin yalnızca “Bu script güvenli mi?” sorusunu değil, “Bu script hangi veriyi topluyor, nereye gönderiyor ve neden gönderiyor?” sorusunu da değerlendirmesi gerekir.

Özellikle Türkiye’de KVKK kapsamında kişisel veri işleme faaliyetleri açısından üçüncü taraf servislerin kullanımı ayrıca değerlendirilmelidir.

Ancak burada önemli bir ayrım vardır: Bir güvenlik tarayıcısının script tespit etmesi, tek başına KVKK ihlali olduğu anlamına gelmez. Scriptin ne yaptığı, hangi veriyi işlediği, hukuki dayanak, aktarım mekanizması ve ilgili veri işleme süreçleri ayrıca değerlendirilmelidir. Bu ayrım yanlış pozitifleri azaltmak açısından oldukça önemlidir.

Üçüncü taraf script güvenliğinde sık yapılan hatalar

1. Kullanılmayan scriptleri kaldırmamak

Web siteleri zaman içerisinde büyür. Bir dönem kullanılan chat widget, analytics, A/B testing, marketing pixel veya heatmap gibi araçlar daha sonra kullanılmayabilir. Ancak script HTML içinde kalmaya devam edebilir. Bu durum gereksiz saldırı yüzeyi oluşturur.

2. Her scripti güvenilir kabul etmek

Bir script Google, Microsoft veya Cloudflare gibi bilinen bir sağlayıcıdan geliyor olsa bile bu otomatik olarak risksiz olduğu anlamına gelmez. Burada amaç sağlayıcıya güvensizlik oluşturmak değil, riskin teknik olarak ölçülmesini sağlamak olmalıdır.

3. CSP kullanmamak

CSP olmadan web uygulamasının JavaScript kaynaklarını kontrol etmek daha zor hale gelebilir. Özellikle çok sayıda üçüncü taraf entegrasyon kullanılan sitelerde CSP önemli bir savunma katmanıdır.

4. SRI kullanmamak

Statik üçüncü taraf kaynaklarda SRI kullanımı dosya bütünlüğünü doğrulamak için önemli bir kontrol olabilir.

5. Eski dependency’leri güncellememek

Eski paketler bilinen güvenlik açıklarına sahip olabilir. Özellikle büyük dependency tree’lerinde düzenli dependency audit yapılması gerekir.

6. Scriptleri production’da sınırsız çalıştırmak

Her scriptin her sayfada çalışması gerekmeyebilir. Örneğin analytics tüm sayfalarda, chat belirli sayfalarda, payment SDK checkout’ta, admin tools yalnızca admin panelinde çalışacak şekilde daha kontrollü bir yapı oluşturulabilir. Bu yaklaşım saldırı yüzeyini azaltabilir.

JavaScript tedarik zinciri güvenliği için kontrol listesi

Bir web sitesinde üçüncü taraf JavaScript kullanılıyorsa aşağıdaki kontroller düzenli olarak yapılmalıdır:

Kaynak kontrolü

• Hangi üçüncü taraf scriptler yükleniyor?
• Scriptler hangi domainlerden geliyor?
• Script sağlayıcıları kim?
• Kullanılmayan scriptler var mı?

Bütünlük

• SRI kullanılıyor mu?
• Harici script içeriği değiştiğinde tespit ediliyor mu?
• CDN kaynakları kontrol ediliyor mu?

CSP

• Content Security Policy mevcut mu?
• script-src gereğinden geniş mi?
• Güvenilmeyen domainlere izin veriliyor mu?
• Inline script kullanımı kontrol altında mı?

Dependency güvenliği

• npm/yarn/pnpm bağımlılıkları güncel mi?
• Bilinen CVE’ler mevcut mu?
• Transitive dependency’ler inceleniyor mu?
• Lock file kullanılıyor mu?

Erişim kontrolü

• Tag Manager hesaplarına kim erişiyor?
• Üçüncü taraf servis hesaplarında MFA aktif mi?
• Gereksiz kullanıcılar kaldırılmış mı?

Veri gizliliği

• Script hangi verileri topluyor?
• Veriler nereye gönderiliyor?
• Kullanıcının rızası gerekiyor mu?
• Privacy/consent mekanizmasıyla uyumlu mu?

GuardBee üçüncü taraf JavaScript risklerini neden önemser?

Web güvenliğinde önemli bir problem, güvenlik bulgularının yalnızca teknik terimlerle raporlanmasıdır. Örneğin “Missing SRI” tek başına bir yönetici için çok anlamlı olmayabilir. Asıl soru şudur: Bu durum işletmem için ne anlama geliyor?

GuardBee’nin yaklaşımı burada teknik bulguyu işletme açısından anlamlandırmaya odaklanır. Bir web sitesindeki JavaScript yüzeyi incelenirken şu akış izlenebilir:

Third-party Scripts
       ↓
Script Sources
       ↓
Security Headers
       ↓
Integrity Controls
       ↓
Potential Risk
       ↓
Recommended Action

Örneğin sistem yalnızca “Harici JavaScript kaynağı kullanılıyor.” demekle yetinmemelidir. Daha anlamlı olan:

Web siteniz üçüncü taraf bir JavaScript kaynağına bağımlı. Kaynak içeriğinin bütünlüğünü doğrulayan SRI mekanizması bulunmuyor. Sağlayıcı tarafında yapılabilecek yetkisiz bir değişiklik, sitenizde çalışan JavaScript kodunu etkileyebilir.

Bu iki bulgu teknik olarak benzer bir noktaya işaret etse de ikinci açıklama riskin neden önemli olduğunu çok daha iyi anlatır.

Her üçüncü taraf script güvenlik açığı değildir

Burada önemli bir noktayı özellikle belirtmek gerekir. Bir web sitesinde Google Analytics, Meta Pixel, Hotjar, Cloudflare, Stripe veya Intercom gibi üçüncü taraf servislerin bulunması otomatik olarak güvenlik açığı olduğu anlamına gelmez.

Aynı şekilde “Sitede 20 adet üçüncü taraf script var.” demek de tek başına anlamlı bir güvenlik bulgusu değildir.

Asıl değerlendirilmesi gereken:

Script var mı?
       ↓
Kaynağı güvenilir mi?
       ↓
Ne yetkisi var?
       ↓
Hangi veriye erişebilir?
       ↓
Bütünlüğü korunuyor mu?
       ↓
CSP ile sınırlandırılmış mı?
       ↓
Gereksiz mi?
       ↓
Risk oluşturuyor mu?

Bu yaklaşım özellikle güvenlik tarayıcılarında false positive problemini azaltmak açısından kritiktir.

Üçüncü taraf JavaScript güvenliği nasıl iyileştirilir?

En iyi yaklaşım tek bir güvenlik mekanizmasına güvenmek yerine birden fazla kontrol katmanı oluşturmaktır.

              Web Application
                     │
          ┌──────────┴──────────┐
          │                     │
         CSP                   SRI
          │                     │
          └──────────┬──────────┘
                     │
             Third-party JS
                     │
          ┌──────────┴──────────┐
          │                     │
     Dependency Audit      Monitoring
          │                     │
          └──────────┬──────────┘
                     │
               Risk Detection

Bu yapı sayesinde bir kontrolün başarısız olması durumunda diğer katmanlar riski azaltabilir.

Sonuç

JavaScript artık modern web uygulamalarının temel yapı taşlarından biri. Ancak uygulamalar büyüdükçe kendi kodumuz ile üçüncü taraf kodlar arasındaki sınır da giderek genişliyor.

Bir analytics scripti, reklam pixel’i, chatbot, ödeme SDK’sı veya npm paketi ilk bakışta küçük bir entegrasyon gibi görünebilir. Fakat bu bileşenlerin her biri uygulamanızın JavaScript tedarik zincirinin bir parçasıdır.

Bu nedenle güvenli bir web uygulaması için yalnızca “Kendi kodumuzda açık var mı?” sorusunu sormak yeterli değildir. Bunun yanında şu soruların da düzenli olarak cevaplanması gerekir:

• Hangi üçüncü taraf kodlara güveniyoruz?
• Bu kodlar değiştirildiğinde bunu fark edebilir miyiz?
• Hangi verilere erişebiliyorlar?
• Kaynaklarını ve bütünlüklerini nasıl doğruluyoruz?
• CSP ile sınırlandırılmış durumdalar mı?
• Gerçekten bu scriptlere ihtiyacımız var mı?

JavaScript tedarik zinciri güvenliği, tek seferlik bir kontrol değil, sürekli takip edilmesi gereken bir güvenlik sürecidir.

GuardBee gibi bir güvenlik platformunun burada sağlaması gereken değer ise yalnızca web sitesinde kaç script bulunduğunu göstermek değil; hangi bileşenlerin güvenlik açısından anlamlı olduğunu ayırt etmek, riski bağlamıyla göstermek ve uygulanabilir bir düzeltme yolu sunmaktır.

Sık sorulan sorular

Üçüncü taraf JavaScript nedir?

Web sitesinin kendi kod tabanı dışında, harici bir sağlayıcıdan yüklenen ve tarayıcıda çalışan JavaScript kodudur. Analytics, reklam, chatbot, ödeme ve A/B testing araçları buna örnek olabilir.

Üçüncü taraf scriptler güvenli midir?

Her üçüncü taraf script güvenlik açığı değildir. Ancak dışarıdan kod çalıştırıldığı için ek bir güven sınırı oluşturur ve düzenli olarak değerlendirilmelidir.

SRI nedir?

Subresource Integrity, tarayıcının harici JavaScript veya CSS dosyasının beklenen içerikle aynı olup olmadığını cryptographic hash üzerinden doğrulamasını sağlayan bir güvenlik mekanizmasıdır.

CSP üçüncü taraf scriptleri engeller mi?

CSP, hangi kaynaklardan script çalıştırılabileceğini kontrol etmek için kullanılabilir. Ancak CSP’nin nasıl yapılandırıldığı önemlidir; aşırı geniş politikalar beklenen güvenlik faydasını azaltabilir.

npm paketleri JavaScript tedarik zincirinin parçası mıdır?

Evet. Doğrudan ve dolaylı (transitive) npm bağımlılıkları uygulamanın JavaScript tedarik zincirinin önemli bir parçasıdır.

Üçüncü taraf scriptler KVKK açısından risk oluşturur mu?

Oluşturabilir. Ancak yalnızca üçüncü taraf script kullanılması otomatik olarak KVKK ihlali anlamına gelmez. Scriptin hangi verileri topladığı, nereye aktardığı ve ilgili veri işleme koşulları ayrıca değerlendirilmelidir.

Bir web sitesinde çok sayıda üçüncü taraf script olması güvenlik açığı mıdır?

Tek başına değildir. Önemli olan scriptlerin kaynağı, davranışı, erişebildiği veriler, güvenlik kontrolleri ve gerçekten gerekli olup olmadığıdır.