JavaScript-də ifşa olunmuş Supabase service role açarı: bu nə deməkdir və necə tapmaq olar

Service role açarının nə olduğu

Supabase hər layihə üçün iki fərqli açar verir: anon açarı (yeni layihələrdə həm də yayımlanabilən açar adlanır) və service_role açarı. Hər ikisi sizin layihənizin JWT secret-i ilə imzalanmış JSON Web Token-lərdir. Fərq JWT payload-ına yazılmış role iddiasıdır — ictimai açar üçün anon, əsas açar üçün service_role. PostgREST, Supabase Storage və Supabase Auth-un hamısı service_role iddiasını gördükdə hər şeyi keçmə rejiminə keçir.

Hər hansı Supabase açarını jwt.io-da deşifrə edin və payload-a baxın. Service-role JWT-nin forması səhv salınmazdır:

Service-role JWT-nin deşifrə olunmuş payload-u (aşağıda sintaksis-vurğulanmış blok kimi göstərilib).

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

Yeni Supabase layihələri JWT əvəzinə sb_secret_ prefiksi olan sirr-stilli açarlar verir. Davranış eynidir — ictimai bundle-də sb_secret_ daşıyan hər hansı şey eyni dərəcədə fəlakətlidir.

AI kodlaşdırma alətləri service role açarını necə sızdırır

Minlərlə vibe-coded tətbiqdə eyni üç nümunəni gördük. Hər biri bir tərtibatçının AI alətdən kömək istəməsi ilə başlayır və service açarının bundle-ə inline edilməsi ilə bitir.

Nümunə 1: NEXT_PUBLIC_ prefiksi ilə tək .env faylı

Tərtibatçı AI alətdən "Supabase quraşdırmağı" istəyir və hər iki açar olan tək bir .env qəbul edir. AI alət — əksər ətraf mühit dəyişənlərinin NEXT_PUBLIC_* vasitəsilə ifşa olunduğu bir korpus üzərində təlim keçmiş — hər ikisini NEXT_PUBLIC_ ilə prefikslədirir. Next.js bu prefiksə uyğun olan hər şeyi build zamanı müştəri bundle-inə inline edir. Vercel-ə deploy edin və service açarı main.[hash].js-dədir.

Nümunə 2: createClient çağırışında səhv açar

Tərtibatçı hər iki açarı AI-nin yaratdığı config.ts faylına yapışdırır və AI səhvən brauzer tərəfli createClient() çağırışını process.env.SUPABASE_SERVICE_ROLE_KEY ilə doldurur. Build dəyişəni daxil edir və JWT bundle-də yer alır.

Nümunə 3: Seed skriptlərində hardcode edilmiş service-role açarı

Tərtibatçı AI alətdən verilənlər bazasını seed edən bir skript yazmasını istəyir. AI service-role açarını (mühit dəyişənindən oxumaq yerinə) birbaşa fayla hardcode edir, faylı reposa commit edir və ictimai GitHub repo və ya deploy olunmuş tətbiqin /scripts/seed.js route-u indi açarı təqdim edir.

FixVibe bundle skanı sızıntını necə aşkarlayır

FixVibe-nin bundle-secrets yoxlaması deploy olunmuş tətbiqin istinad etdiyi hər JavaScript faylını yükləyir — giriş chunk-ları, lazy-yüklənən chunk-lar, web worker-lər, service worker-lər — və onları JWT formasına uyğun (eyJ[base64-header].eyJ[base64-payload].[signature]) hər şeyi deşifrə edən detektor üzərindən keçirir. Deşifrə olunmuş payload-da "role": "service_role" varsa, skan bunu kritik tapıntı kimi fayl yolu və açarın göründüyü dəqiq sətirlə birlikdə bildirir. Eyni yoxlama daha yeni sb_secret_* nümunəsini də prefiksə görə uyğunlaşdırır.

Skan heç vaxt aşkarlanan açarla identifikasiya olunmur. O, formanı müəyyən edir və sızıntını bildirir — istismar oluna bilərliyi sübut etmək üçün açarı istifadə etmək verilənlər bazanıza icazəsiz giriş olardı. Sübut JWT payload-ının özündədir.

Aşkarlandı — ilk saatda nə etməli

Sızdırılan service role açarı işləyiş zamanı təcili haldır. Açarın artıq toplandığını fərz edin — hücumçular ictimai bundle-ləri real vaxtda izləyir. Açarı rotasiya edib son fəaliyyəti audit edənə qədər verilənlər bazasını risk altında hesab edin.

1. Açarı dərhal rotasiya edin. Supabase Dashboard-da Project Settings → API → Service role key → Reset gedin. Köhnə açar saniyələr ərzində etibarsız olur. Açarı istifadə edən hər server tərəfli kod rotasiya icra olunmazdan əvvəl yenilənməli və yenidən deploy edilməlidir.
2. Son verilənlər bazası fəaliyyətini audit edin. Dashboard-da Database → Logs açın. Son 7 günə filtr verin. PII olan cədvəllərə qarşı qeyri-adi SELECT * sorğularını, böyük UPDATE və ya DELETE ifadələrini və məlum infrastrukturunuzdan kənar IP-lərdən gələn sorğuları axtarın. Supabase hər sorğuda x-real-ip başlığını qeyd edir.
3. Storage obyektlərini yoxlayın. Storage → Logs bölməsinə daxil olun və son fayl yükləmələrini nəzərdən keçirin. Sızdırılan service-role açarı şəxsi bucket-lərə də hər şeyi keçmə girişi verir.
4. Açarı versiya idarəetməsindən silin. Rotasiyadan sonra belə, JWT-nin git tarixçəsində qalması onun ictimai repoda kəşf edilə bilməsi deməkdir. Onu tarixçədən təmizləmək üçün git filter-repo və ya BFG Repo-Cleaner istifadə edin və sonra force-push edin (əvvəlcə əməkdaşları xəbərdar edin).
5. Düzəlişdən sonra yenidən skanlayın. Yenidən deploy olunmuş tətbiqə qarşı təzə FixVibe skanı işlədin. Bundle-secrets tapıntısı təmizlənməlidir. Heç bir chunk-da service_role JWT və ya sb_secret_* sətrinin qalmadığını təsdiqləyin.

Sızıntını ilk növbədə qarşısını almaq

Struktur düzəlişi adlandırma intizamı və alət səviyyəsində qoruyucular əlavə etməkdir:

• Service açarını heç vaxt NEXT_PUBLIC_*, VITE_* və ya başqa hər hansı bundle-inline prefiksi ilə prefikslədmeyin. Adlandırma konvensiyası sərhəddir — hər framework ona hörmət edir.
• Tərtibatçı maşınında service açarını .env-dən tamamilə kənarda saxlayın. Onu deploy zamanı bir sirr menecerindən (Doppler, Infisical, Vercel şifrələnmiş env dəyişənləri) oxuyun, lokal olaraq heç vaxt commit etməyin.
• <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 çıxışını skanlayan CI gate əlavə edin. next build sonrası .next/static/chunks/ çıxışında service_role sətrini grep edin. Hər hansı uyğunluq varsa build-i fail edin.

# 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

Tez-tez verilən suallar

Sonrakı addımlar

Produksiya URL-inizə qarşı FixVibe skanı işlədin — bundle-secrets yoxlaması pulsuzdur, qeydiyyat tələb etmir və bir dəqiqədən az müddətdə service_role ifşasını bildirir. Bunu RLS qatının işini yerinə yetirdiyini doğrulamaq üçün Supabase RLS skaneri məqaləsi və fayl girişini bağlamaq üçün Supabase storage bucket təhlükəsizlik yoxlama siyahısı ilə birləşdirin. AI alətlərinin bu sızıntı sinifini niyə bu qədər ardıcıl yaratdığına dair fon məlumat üçün AI kodlaşdırma alətləri niyə təhlükəsizlik boşluqları buraxır oxuyun.