JavaScript'te ifşa olan Supabase service role anahtarı: ne anlama geldiği ve nasıl bulunacağı

Service role anahtarı nedir

Supabase her proje için iki farklı anahtar verir: anon anahtarı (daha yeni projelerde yayınlanabilir anahtar olarak da adlandırılır) ve service_role anahtarı. İkisi de projenizin JWT secret'ı ile imzalanmış JSON Web Token'lardır. Fark, JWT yüküne gömülmüş role claim'idir — public anahtar için anon, ana anahtar için service_role. PostgREST, Supabase Storage ve Supabase Auth, service_role claim'ini gördüklerinde her şeyi atlama moduna geçer.

Herhangi bir Supabase anahtarını jwt.io'da çözün ve yüke bakın. Bir service-role JWT'sinin şekli açıkça tanınabilir:

Bir service-role JWT'sinin çözülmüş yükü (aşağıda sözdizimi vurgulu bir blok olarak gösterilmiştir).

{
  "iss": "supabase",
  "ref": "[project-ref]",
  "role": "service_role",
  "iat": 1700000000,
  "exp": 2000000000
}

Daha yeni Supabase projeleri, JWT yerine sb_secret_ önekiyle gizli anahtar tarzı anahtarlar verir. Davranış aynıdır — public bir pakette sb_secret_ taşıyan herhangi bir şey eşit derecede felakettir.

Yapay zeka kodlama araçları service role anahtarını nasıl sızdırır

Binlerce vibe-coded uygulamada aynı üç deseni gördük. Her biri bir geliştiricinin yapay zeka aracından yardım istemesiyle başlar ve service anahtarının bir pakete satır içi alınmasıyla biter.

Desen 1: NEXT_PUBLIC_ önekli tek bir .env dosyası

Geliştirici yapay zeka aracına "Supabase'i kur" der ve her iki anahtarı içeren tek bir .env kabul eder. Çoğu ortam değişkeninin NEXT_PUBLIC_* üzerinden ifşa edildiği bir derlem üzerinde eğitilmiş yapay zeka aracı — her ikisini de NEXT_PUBLIC_ ile öneklendirir. Next.js bu önekle eşleşen her şeyi build zamanında istemci paketine satır içi alır. Vercel'e gönderin ve service anahtarı main.[hash].js içindedir.

Desen 2: createClient çağrısında yanlış anahtar

Geliştirici her iki anahtarı da yapay zekanın oluşturduğu bir config.ts dosyasına yapıştırır ve yapay zeka, tarayıcı tarafı createClient() çağrısını yanlışlıkla process.env.SUPABASE_SERVICE_ROLE_KEY ile doldurur. Build değişkeni çeker ve JWT pakete iner.

Desen 3: Seed scriptlerinde sabit kodlanmış service-role anahtarı

Geliştirici yapay zeka aracından veritabanını seed eden bir script yazmasını ister. Yapay zeka service-role anahtarını doğrudan dosyaya sabit kodlar (ortamdan okumak yerine), dosyayı repoya commit eder ve public GitHub repo'su veya dağıtılmış uygulamanın /scripts/seed.js rotası artık anahtarı sunar.

FixVibe paket taraması sızıntıyı nasıl tespit eder

FixVibe'ın bundle-secrets kontrolü, dağıtılmış uygulama tarafından referans verilen her JavaScript dosyasını indirir — giriş parçaları, lazy yüklenen parçalar, web worker'lar, service worker'lar — ve bunları JWT şekline (eyJ[base64-header].eyJ[base64-payload].[signature]) uyan her şeyi çözen bir dedektörden geçirir. Çözülmüş yük "role": "service_role" içeriyorsa, tarama dosya yolu ve anahtarın göründüğü tam satırla birlikte bunu kritik bir bulgu olarak raporlar. Aynı kontrol önek bazlı olarak yeni sb_secret_* desenini de eşleştirir.

Tarama keşfedilen anahtarla asla kimlik doğrulamaz. Şekli tanımlar ve sızıntıyı raporlar — sömürülebilirliği kanıtlamak için anahtarı kullanmak veritabanınıza yetkisiz erişim olur. Kanıt JWT yükünün kendisindedir.

Tespit edildi — ilk saatte ne yapmalı

Sızdırılan bir service role anahtarı bir çalışma zamanı acil durumudur. Anahtarın kazındığını varsayın — saldırganlar public paketleri gerçek zamanlı izler. Anahtarı döndürene ve son aktiviteyi denetleyene kadar veritabanını ele geçirilmiş olarak değerlendirin.

1. Anahtarı hemen döndürün. Supabase Dashboard'da Project Settings → API → Service role key → Reset'e gidin. Eski anahtar saniyeler içinde geçersizleştirilir. Anahtarı kullanan herhangi bir sunucu tarafı kod, rotasyon inmeden önce güncellenip yeniden dağıtılmalıdır.
2. Son veritabanı aktivitesini denetleyin. Dashboard'da Database → Logs'u açın. Son 7 güne filtreleyin. PII içeren tablolara karşı olağandışı SELECT * sorgularına, büyük UPDATE veya DELETE ifadelerine ve bilinen altyapınızın dışındaki IP'lerden gelen isteklere bakın. Supabase her isteğe x-real-ip başlığını loglar.
3. Storage nesnelerini kontrol edin. Storage → Logs'u ziyaret edin ve son dosya indirmelerini gözden geçirin. Sızdırılan bir service-role anahtarı, private kovalara da her şeyi atlama erişimi verir.
4. Anahtarı sürüm kontrolünden kaldırın. Rotasyondan sonra bile JWT'yi git geçmişinizde bırakmak, public repo'da keşfedilebilir olduğu anlamına gelir. Geçmişten silmek için git filter-repo veya BFG Repo-Cleaner kullanın, sonra force-push yapın (önce işbirlikçileri uyarın).
5. Düzeltmeden sonra yeniden tarayın. Yeniden dağıtılan uygulamaya karşı yeni bir FixVibe taraması çalıştırın. Bundle-secrets bulgusu temizlenmiş olmalı. Hiçbir parçada service_role JWT'sinin ve hiçbir sb_secret_* dizesinin kalmadığını teyit edin.

Sızıntıyı en başında önlemek

Yapısal düzeltme adlandırma disiplini artı araç düzeyinde önlemlerdir:

• Service anahtarını asla NEXT_PUBLIC_*, VITE_* veya pakete satır içi alma yapan başka bir önekle öneklendirmeyin. Adlandırma kuralı sınırdır — her framework buna saygı duyar.
• Service anahtarını geliştirici makinesinde .env içinden tamamen uzak tutun. Onu dağıtımda bir secret manager'dan (Doppler, Infisical, Vercel şifrelenmiş env vars) okuyun, yerel olarak asla commit etmeyin.
• <strong>Mark every Supabase client construction with explicit context.</strong> Files named <code>supabase/browser.ts</code> use the anon key; files named <code>supabase/server.ts</code> use the service-role key with <code>import 'server-only'</code> at the top. The <code>server-only</code> import causes a build error if a client component tries to consume the module.
• <strong>Add a pre-commit hook that greps for JWT-shaped strings.</strong> <code>git diff --staged | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+'</code> catches both anon and service tokens before they leave your machine.
• Build çıktısını tarayan bir CI kapısı ekleyin. next build'den sonra .next/static/chunks/ çıktısını service_role dizesi için grep'leyin. Herhangi bir şey eşleşirse build'i başarısız yapın.

# Pre-commit hook: refuse any staged JWT-shaped string.
git diff --staged \
  | grep -E 'eyJ[A-Za-z0-9_-]+\.eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+' \
  && echo "JWT detected in staged changes — refusing commit" \
  && exit 1

# CI gate: fail the build if "service_role" shipped to the static bundle.
grep -RE 'service_role|sb_secret_' .next/static/chunks/ \
  && echo "Service-role credential leaked into bundle" \
  && exit 1

Sık sorulan sorular

Sonraki adımlar

Üretim URL'nize karşı bir FixVibe taraması çalıştırın — bundle-secrets kontrolü ücretsizdir, kayıt gerekmez ve service_role ifşasını bir dakikadan kısa sürede raporlar. Bunu RLS katmanının işini yapıp yapmadığını doğrulamak için Supabase RLS tarayıcısı makalesiyle ve dosya erişimini kilitlemek için Supabase storage bucket güvenlik kontrol listesi ile eşleştirin. Yapay zeka araçlarının bu sızıntı sınıfını neden bu kadar güvenilir şekilde ürettiğine dair arka plan için Yapay zeka kodlama araçları neden güvenlik açıkları bırakır bölümünü okuyun.