Frontend'de Unutulan Sırlar: Hackerlar JavaScript Dosyalarından Neleri Çalıyor?

Modern web uygulamaları (SPA - Single Page Applications) geliştirilirken, backend mantığının büyük bir kısmı istemci (frontend) tarafına kaymıştır. React, Vue.js veya Angular gibi yapılar kullanarak sitenizi derlediğinizde (npm run build), tüm o süslü arayüz devasa bir app.bundle.js dosyasına dönüşür ve kullanıcının tarayıcısına aktarılır.

Ancak geliştiricilerin en büyük kör noktası şudur: Tarayıcıya inen hiçbir şey "gizli" değildir. Siber korsanlar veya hata ödül avcıları (Bug Bounty Hunters), sitenize girdiklerinde tasarımla ilgilenmez; doğrudan F12 araçlarından .js dosyalarınızı parçalamaya başlarlar.

Temel Değerlendirme: JavaScript kaynak kodlarınızda veya .js.map (Source Map) dosyalarınızda "test amaçlı" veya kazara bıraktığınız AWS anahtarları, Stripe API token'ları, Firebase yapılandırmaları ve JWT gizli anahtarları saniyeler içinde özel otomasyon botları tarafından çekilir (extract). Kodunuzda const API_KEY = "sk_live_..." gibi bir değişkenin barınması, bir hacker'ın iç ağınıza veya şirket ödeme altyapınıza sızması için tek başına yeterlidir.

Bu makalede frontend tarafında en sık rastlanan gizli bilgi sızıntılarını (Secrets Exposure) ve Eresus Security uzmanlarının Black Box sızma testlerinde bu verileri nasıl ayıkladığını inceliyoruz.

---

1. Hackerlar JS Dosyalarını Nasıl İnceler?

Sıradan bir kullanıcı siteye girdiğinde sadece butonları ve metinleri görür. Bir pentester ise şu süreci işletir:

1. Recon (Keşif): Siteye ait tüm JS, JSON ve CSS dosyaları yakalanır.
2. Beautify / Deobfuscation: Sıkıştırılmış (minified) ve okunmaz hale getirilmiş (obfuscated) kod, otomatik araçlarla okunaklı hale getirilir.
3. Regex Analizi: Özel tanımlanmış Kurallı İfadeler (Regular Expressions) ile dosyanın içinde hızlı bir tarama yapılır. Örneğin AKIA[0-9A-Z]{16} gibi bir desen arandığında, siber korsan direkt olarak kodda unutulmuş bir AWS Access Key ID bulur.

2. En Sık Açığa Çıkan Hassas Bilgiler (Secrets)

A. Gizli Olmayan Bulut Servisi Anahtarları

Özellikle Firebase, Supabase veya AWS S3 kullanan frontend projelerinde, geliştiriciler servislere bağlanmak için anahtarları kod içerisine donanımsal (hardcoded) olarak gömerler. "Sadece arayüze veri çekiyor, tehlikesi yok" diye düşünülen bir Firebase konfigürasyonu, eğer veritabanı kuralları (Database Rules) yanlış yazılmışsa hackerın tüm müşteri veritabanınızı tek bir curl komutuyla silmesine neden olabilir.

B. Özel (Private) API Endpoints ve Yönlendirmeler

Hackera yetki vermek bazen şifreyle değil, nereye saldıracağını göstermekle olur. JavaScript dosyalarınızda yorum satırı içerisinde unutulmuş // TODO: Test uat-admin.website.com/api/v2/users şeklindeki bir ibare, şirketin gizli tuttuğunu sandığı test (UAT) ortamlarının deşifre olmasına neden olur.

C. Source Map (Kaynak Haritası) Unutkanlığı

Uygulamanız canlıya (Production) geçerken asıl React kodlarını şifreler, ancak eğer app.js.map tarzı dosya uzantıları sunucuda bırakılırsa, herkes orijinal kaynak kodunuzu hiyerarşik dosyalarıyla birlikte, aynen VSCode'da yazmışsınız gibi aynısı okuyabilir.

---

3. Kodumdan API Anahtarını Çaldırmak İstemiyorum, Ne Yapmalıyım?

• 1. Çevre Değişkenleri (Environment Variables) Doğru Kullanımı: API anahtarlarınızı process.env gibi çevre değişkenlerinde tutmak frontend tarafında yüzde yüz güvenli değildir. Eğer kodun çalışması için tarayıcıda o anahtara ihtiyaç varsa (örneğin Stripe Publishable Key), bu anahtar zaten ağ trafiğine çıkacaktır. Hassas anahtarları (Secret Keys) kesinlikle Backend'te (Node.js, Go) tutmalı ve Frontend'i sadece bir aracı olarak kullanmalısınız.
• 2. CI/CD Boru Hattı Taraması: Git deponuza (repository) kod pushlamadan önce GitLeaks, TruffleHog gibi araçlarla commit geçmişinizi "secret" sızıntılarına karşı taratın.
• 3. Source Map Devre Dışı Bırakma: Production ortamı derlenirken framework ayarlarınızdan "SourceMap generation" özelliğini false konumuna getirin.

Uzman Uyarısı: JS Dosyalarındaki sızıntılar sadece yapısal okumalarla (statik analiz) bulunur ve genelde şirket içi geliştiricilerin radarına girmez.

Web tabanlı uygulamalarınızın hem statik (SAST) hem de dinamik (DAST) olarak analiz edilmesi ve istemci tarafı kör noktalarının ortadan kaldırılması için Eresus Security AppSec test uzmanlarıyla iletişime geçebilir, güvenli yazılım geliştirme döngünüzü optimize edebilirsiniz.

Temel Değerlendirme

Frontend'de Unutulan Sırlar: Hackerlar JavaScript Dosyalarından Neleri Çalıyor? konusu yalnızca teknik bir ayrıntı değildir; yanlış ele alındığında veri sızıntısı, yetki aşımı, operasyon kesintisi veya regülasyon riski doğurur. En doğru yaklaşım, varlıkları ve kullanıcı rollerini netleştirip gerçek saldırı yolunu kanıtla test etmek, ardından düzeltmeyi ölçülebilir retest kriterine bağlamaktır.

Neden Kritik?

• Saldırganlar çoğu zaman en zayıf teknik kontrolü değil, en zayıf varsayımı hedefler.
• Otomatik taramalar bilinen kalıpları yakalayabilir ama iş etkisini ve zincirleme saldırı yolunu tek başına göstermez.
• Güvenlik çıktısı geliştirici, yönetici ve uyum ekibi tarafından aynı şekilde anlaşılmıyorsa aksiyona dönüşmez.

Pratik Senaryo

Bir ekip sistemi güvenli kabul eder çünkü login çalışır, pipeline yeşildir veya model beklenen cevabı üretir. Ancak saldırgan aynı akışta farklı kullanıcı, farklı tenant, farklı dosya veya farklı token ile deneme yaptığında tasarımın sakladığı gerçek risk ortaya çıkar. Bu yüzden testler mutlu yol yerine kötüye kullanım senaryolarıyla yazılmalıdır.

Yanlış Bilinenler

• “Araç taradı, kritik yok” güvenlik onayı değildir.
• “İç sistem, saldırgan erişemez” varsayımı modern saldırı zincirlerinde zayıftır.
• “Bu sadece teknik borç” denilen konu çoğu zaman müşteri verisi veya production erişimiyle birleşir.

Karar Tablosu

| Durum | Risk seviyesi | Önerilen aksiyon | | --- | --- | --- | | Demo veya izole test ortamı | Düşük-Orta | Mimari kararları ve veri akışını belgeleyin | | Staging production verisine yakın | Orta-Yüksek | Yetki, log ve abuse testlerini ekleyin | | Production veya müşteri verisi | Yüksek | Profesyonel assessment, remediation ve retest planlayın |

Kontrol Listesi

• Client bundle içinde secret veya endpoint bilgisi var mı?
• Admin ve kullanıcı rolleri gerçek işlemlerde ayrışıyor mu?
• Ödeme veya sipariş akışı manipüle edilebiliyor mu?
• Frontend kontrolü server-side doğrulanıyor mu?
• Source map veya debug asset production’da açık mı?

Ne Zaman Profesyonel Destek Gerekir?

Uygulama ödeme, kullanıcı hesabı, admin paneli, üçüncü parti entegrasyon veya hassas client-side veri içeriyorsa profesyonel web/appsec pentest gerekir.

Eresus Yaklaşımı

Eresus Security bulguları yalnızca başlık olarak raporlamaz. Her bulgu için tekrar üretilebilir kanıt, iş etkisi, önerilen düzeltme, sorumlu ekip ve retest koşulu yazılır.

Eresus Security, web uygulama ve frontend/backend sınırlarında secret exposure, business logic, authorization, ödeme akışı ve abuse senaryolarını manuel kanıtla test eder.

Uygulama Planı

1. Kapsamı Netleştir

• Etkilenen varlıkları, kullanıcı rollerini ve veri sınıflarını çıkarın.
• Normal kullanıcı akışıyla saldırgan akışını ayrı ayrı yazın.
• Hariç tutulan sistemleri ve test sınırlarını açıkça belirtin.

2. Kanıt Üret

• Bulguyu tek ekran görüntüsüne değil, tekrar üretilebilir adımlara bağlayın.
• Etkiyi teknik hata ve iş sonucu olarak ayrı açıklayın.
• Log, request ID, test hesabı ve zaman bilgisini not edin.

3. Retest Kriterini Belirle

• Düzeltmenin ne zaman tamam sayılacağını önceden yazın.
• Aynı sınıf hatanın başka endpoint veya akışlarda olup olmadığını kontrol edin.
• Bulguyu kapatmadan önce negatif test senaryosunu yeniden çalıştırın.

Sık Sorulan Sorular

Frontend'de Unutulan Sırlar: Hackerlar JavaScript Dosyalarından Neleri Çalıyor? için ilk adım nedir?

İlk adım sistemin hangi veriye, hangi kimlikle ve hangi iş akışı üzerinden eriştiğini çıkarmaktır. Araç seçimi bundan sonra anlamlı hale gelir.

Otomatik araçlar bu riski tamamen yakalar mı?

Hayır. Otomatik araçlar başlangıç için faydalıdır, fakat yetki sınırı, iş mantığı, zincirleme etki ve gerçek istismar kanıtı manuel analiz gerektirir.

Bu çalışma çıktısı nasıl aksiyona dönüşür?

Her bulgu bir remediation sahibi, öncelik, iş etkisi ve retest kriteriyle yazıldığında doğrudan güvenlik backlog’una veya sprint planına girebilir.

Eresus bu konuda nasıl destek olur?

Eresus Security kapsam çıkarma, teknik test, kanıt üretimi, remediation danışmanlığı ve retest aşamalarını tek çalışma akışında destekler.

Raporlama ve İç Link Stratejisi

• Yazı ilgili hub sayfasına bağlanmalı ve okuyucuya bir sonraki teknik adımı göstermelidir.
• Aynı pillar içindeki en az iki destekleyici bloga bağlantı verilmelidir.
• Hizmet CTA’sı genel iletişim çağrısı gibi değil, okuyucunun karar anına uygun şekilde yazılmalıdır.
• Raporlama dili teknik kanıt, iş etkisi ve düzeltme önceliğini aynı yerde göstermelidir.

Retest Kapanış Kriteri

Bir bulgu yalnızca düzeltme yapıldı diye kapanmış sayılmaz. Aynı saldırı adımı tekrar denendiğinde başarısız olmalı, loglarda beklenen kayıt oluşmalı ve benzer akışlarda aynı sınıf hata bulunmamalıdır. Bu yaklaşım içeriği sadece bilgilendirici olmaktan çıkarıp uygulamaya dönük hale getirir.