// docs / baas security / umbrella scanner
BaaS yanlış yapılandırma tarayıcısı: kullanıcılardan önce public veri yollarını bulun
Backend-as-a-Service sağlayıcıları — Supabase, Firebase, Clerk, Auth0, Appwrite, Convex — hepsi güvenlikte aynı şekilde başarısız olur: platform mantıklı varsayılanlar gönderir, geliştirici (veya yapay zeka kodlama aracı) bir kestirme yola başvurur ve kimliği doğrulanmamış bir saldırgan ile müşteri verisi arasında public bir yol açılır. Bir BaaS yanlış yapılandırma tarayıcısı, o yolu bir saldırganın yapacağı şekilde dışarıdan sondalayan tek araçtır. Bu makale beş tekrarlayan yanlış yapılandırma sınıfını eşler, şemsiye FixVibe BaaS taramasının nasıl çalıştığını açıklar, dört ana sağlayıcıyı karşılaştırır ve BaaS farkındalıklı tarayıcıyı genel DAST araçlarına karşı karşılaştırır.
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 webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
FixVibe şemsiye BaaS taraması nasıl çalışır
FixVibe'ın BaaS aşaması, her biri farklı bulgular üreten üç aşamada çalışır:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- 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_roleJWT veyasb_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 truekuralları; 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ı, üretimdepk_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:
| Açı | FixVibe (BaaS farkındalıklı DAST) | Genel DAST (Burp / ZAP) | SAST / SCA (Snyk / Semgrep) |
|---|---|---|---|
| BaaS kapsamı | Supabase, Firebase, Clerk, Auth0, Appwrite için yerel kontroller | Genel web tarama; sağlayıcıya özgü sonda yok | Yalnızca repo'nun statik analizi; üretim doğrulaması yok |
| Kurulum süresi | URL → run → results usually in under a minute | Saatler: spider, auth, kapsam yapılandırın | Gün: repo CI'sine entegre edin |
| Neyi kanıtlar | HTTP düzeyinde kanıtla üretim çalışma zamanı ifşası | Web-app açıkları (XSS, SQLi); BaaS manuel yapılandırmayla | Dağıtılmış olabilen veya olmayabilen kod desenleri |
| JavaScript paket incelemesi | Every shipped chunk, with provider-aware key detection | Sınırlı — yalnızca string tabanlı grep | Evet, ama yalnızca repo tarafı, dağıtılmamış |
| Sürekli tarama | API + MCP aracılığıyla aylık / dağıtımda | Manuel; programı kendiniz yapılandırın | Commit başına (kod için iyi, çalışma zamanına kör) |
| Solo / küçük ekip için fiyat | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
Sık sorulan sorular
Uygulamam iki BaaS sağlayıcısı (örn. Supabase + Clerk) kullanıyorsa şemsiye tarama çalışır mı?
Evet — sağlayıcı parmak izi ve sağlayıcı başına sondalar bağımsızdır. Tarayıcı her ikisini de tespit eder, her iki kontrol paketini de çalıştırır ve sağlayıcılar arası korelasyonları raporlar (örn. eksik RLS ile birlikte Clerk'ten email'i bir claim olarak gönderen bir Supabase JWT şablonu).
Bu, uygulamama karşı Burp Suite Pro çalıştırmaktan nasıl farklıdır?
Burp genel bir DAST iş tezgahıdır. Kutudan çıktığı gibi Burp, PostgREST'in, Firestore'un veya Auth0 callback yolunun ne olduğunu bilmez — kapsamı manuel olarak yapılandırmanız, eklentiler yazmanız ve yanıtları yorumlamanız gerekir. FixVibe yerleşik BaaS sondaları ve BaaS şeklinde kanıt biçimlendirmesi ile gelir. Burp genel web-app kapsamında (XSS, SQLi, iş mantığı) kazanır; FixVibe BaaS'a özgü bulgularda kazanır.
App Check (Firebase) veya attestation (Apple / Google) hakkında ne demek?
App Check, fırsatçı harici taramaların her sondajda 403 döndürmesini sağlar — kötü niyetli bir bot için doğru sonuç. Attest edilmemiş bir istemciden gelen bir FixVibe taraması aynı şekilde davranır. App Check etkinse ve FixVibe hâlâ bulgular raporluyorsa, kurallarınızın attest edilmiş istemcilere de açık olduğu anlamına gelir, ki gerçek risk budur. App Check + doğru kurallar derinlikli savunma desenidir.
Tarayıcı düzeltmemi doğrulayabilir mi?
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
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.