BaaS yanlış yapılandırma tarayıcısı: kullanıcılardan önce public veri yollarını bulun

BaaS yanlış yapılandırmalarının neden tekrarlayan bir şekli var

Her BaaS platformu aynı mimariyi izler: yönetilen bir backend ve tarayıcıdan onunla konuşan ince bir istemci SDK'sı. Tarayıcıya dönük istemcinin backend'e kendisini tanımlamak için bir kimlik bilgisine ihtiyacı vardır — bir anon anahtarı, bir yayınlanabilir anahtar, bir Firebase proje kimliği. Bu kimlik bilgisi kasıtlı olarak public'tir; mimarinin güvenliği, platform düzeyindeki erişim kontrollerinin (RLS, kurallar, allowlist'ler) işini yapmasına dayanır.

Yapay zeka kodlama araçları bu mimarinin üzerine platform kontrolleri katmanını içselleştirmeden inşa eder. İstemci SDK'sını doğru şekilde bağlarlar, platformun varsayılan müsamahakar kurallarını (tutorial dostu olması için var olan) kabul ederler ve dağıtırlar. Tekrarlayan şekil şudur: public kimlik bilgisi + müsamahakar varsayılan kural + eksik geçersiz kılma = veri ifşası. Aşağıdaki beş yanlış yapılandırma sınıfı tümü bu şeklin varyantlarıdır.

Beş tekrarlayan yanlış yapılandırma sınıfı

Bunlar her BaaS sağlayıcısında görünür. Eksiksiz bir tarama, kullanımdaki her sağlayıcıya karşı beşini de kapsar:

Sınıf 1: Tarayıcı paketinde yanlış anahtar

Tarayıcı, public/anon eşdeğeri yerine secret/admin anahtarını (Supabase service_role, Firebase Admin SDK private key, Clerk sk_*, Auth0 client secret) gönderir. Tarayıcı kısıtlanmamış bir admin istemcisi olur. FixVibe'ın bundle-secrets kontrolü tarafından kapsanır.

Sınıf 2: Erişim kontrol katmanı devre dışı veya müsamahakar

RLS kapalı, Firebase kuralları if true, Auth0 callback listesi joker karakter. Tarayıcıdaki kimlik bilgisi doğru — ancak onu kısıtlaması gereken platform düzeyindeki sınır işini yapmıyor.

Sınıf 3: Hassas kaynakların anonim okumaları

Anon-okunabilir Firestore koleksiyonları, anon-listelenebilir Supabase storage bucket'ları, anon-erişilebilir Auth0 management API. Tarama şunu sorar: "Hiçbir kimlik bilgisi olmadan ne okuyabilirim?"

Sınıf 4: Üretimde test-modu kalıntıları

Bir üretim deployment'ında test anahtarları (pk_test_*, sb_test_*); canlı domain'den erişilebilen dev-mode Firebase uygulamaları; üretimden daha zayıf ayarlara sahip test-kiracılı Auth0 uygulamaları. Tarama, çalışma zamanı anahtarlarını beklenen üretim önekleriyle karşılaştırır.

Sınıf 5: Webhook imza doğrulaması eksik

Clerk webhook'ları, Stripe webhook'ları, Supabase webhook'ları hepsi yüklerini imzalar. İmzayı doğrulamayan bir işleyici, URL'yi tahmin eden herhangi bir saldırgan için bir veritabanı-yazma primitive'idir. Yanıt şekli aracılığıyla tespit edilir — bir 200 alan imzasız bir istek, doğrulamanın atlandığı anlamına gelir.

FixVibe şemsiye BaaS taraması nasıl çalışır

FixVibe'ın BaaS aşaması, her biri farklı bulgular üreten üç aşamada çalışır:

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. Aşama 2 — sağlayıcıya özgü sondalar. Tespit edilen her sağlayıcı için tarayıcı sağlayıcıya özgü kontrolü çalıştırır: baas.supabase-rls PostgREST'i sondar; baas.firebase-rules Firestore + RTDB + Storage'ı sondar; baas.clerk-auth0 paketlenmiş anahtarların önekini doğrular; bundle-secrets kontrolü hiçbir service-katmanı kimlik bilgisinin sızmadığını doğrular. Her sonda bağımsız çalışır — bir Supabase bulgusu Firebase taramasını engellemez.
3. Aşama 3 — sağlayıcılar arası korelasyon. Tarayıcı bulguları çapraz referans eder. Eksik RLS ile birlikte sızdırılan bir Supabase service-role anahtarı, her iki bulgudan tek başına daha şiddetlidir — rapor bunu su yüzüne çıkarır. Aynı uygulamada birden fazla kimlik sağlayıcısı (Clerk + Auth0 + özel auth) inceleme için işaretlenen yapısal bir bulgudur.

Her sonda pasiftir: kaynak başına en fazla bir anonim okuma, yanıt şekli kaydedilir ancak satır içerikleri asla sayfalanmaz veya saklanmaz. Yazma ve değiştirme sondaları doğrulanmış domain sahipliği arkasında kapılıdır — doğrulanmamış hedeflere karşı asla çalışmazlar.

Tarayıcı sağlayıcı başına ne bulur

Her BaaS sağlayıcısının farklı bir yüzeyi ve farklı bir tarama stratejisi vardır. İşte neyin kapsandığı:

• Supabase: tablolarda eksik RLS, anon-listelenebilir storage bucket'ları, pakette sızdırılan service_role JWT veya sb_secret_* anahtarı, anonim OpenAPI listeleme yoluyla ifşa edilen şemalar. Supabase RLS tarayıcısı ve Storage kontrol listesi'ne bakın.
• Firebase: Firestore, Realtime Database ve Cloud Storage'da if true kuralları; anon-listelenebilir Storage bucket'ları; eksik App Check zorlaması. Firebase kuralları tarayıcısı ve If-true kural açıklayıcısı'na bakın.
• Clerk: paketlenmiş sk_* gizli anahtarları, üretimde pk_test_*, eksik webhook imza doğrulaması, joker karakterli izin verilen origin'ler. Clerk kontrol listesi'ne bakın.
• Auth0: paketlenmiş client secret'ları, etkinleştirilmiş Implicit grant, joker karakterli callback / logout URL'leri, SPA'larda eksik PKCE. Auth0 kontrol listesi'ne bakın.

Bir BaaS tarayıcısı genel DAST ve SAST araçlarına nasıl kıyaslanır

BaaS farkındalıklı bir tarayıcı, diğer araçların yapmadığı belirli işleri yapar. Karşılaştırma:

Dürüst kapsam: bu tarayıcının yerine geçmediği şeyler

BaaS farkındalıklı bir DAST tarayıcısı odaklı bir araçtır, tam bir güvenlik programı değil. Yapmaz:

• SAST veya SCA'nın yerine geçmez. Statik analiz, bir DAST tarayıcısının yapamayacağı bağımlılık CVE'leri (Snyk, Semgrep) ve kod düzeyinde güvenlik açıkları (SonarQube) bulur. Her ikisini de çalıştırın.
• Manuel penetrasyon testinin yerine geçmez. Bir insan pentester, hiçbir tarayıcının bulamayacağı iş mantığı kusurları, yetkilendirme uç durumları ve zincirleme güvenlik açıkları bulur. Büyük bir lansman veya uyumluluk denetiminden önce bir pentester kiralayın.
• Kodunuzu veya repo'nuzu git geçmişindeki gizli bilgiler için denetlemez. Bundle-secrets kontrolü şu anda dağıtılmış olanı kapsar, tarihsel olarak commit edilmiş olanı değil. Repo hijyeni için git-secrets veya gitleaks kullanın.
• BaaS olmayan backend hizmetlerini kapsamaz. Uygulamanız özel bir backend (Express, Rails, Django, FastAPI) kullanıyorsa, FixVibe HTTP yüzeyini tarar ancak arkasındaki veritabanını veya altyapıyı sondalamaz. Bu genel DAST + SAST bölgesidir.

Sık sorulan sorular

Sonraki adımlar

Üretim URL'nize karşı ücretsiz bir FixVibe taraması çalıştırın — BaaS aşaması kontrolleri ücretsiz katman dahil her planda dağıtılır. Sağlayıcıya özgü derinlemesine incelemeler için bu bölümdeki bireysel makaleler her sağlayıcıyı ayrıntılı olarak kapsar: Supabase RLS, Supabase service-key ifşası, Supabase storage, Firebase kuralları, Firebase if-true, Clerk ve Auth0.