Supabase service role key terekspos di JavaScript: apa artinya dan cara menemukannya

Apa itu service role key

Supabase menerbitkan dua key berbeda untuk setiap proyek: key anon (juga disebut publishable key di proyek yang lebih baru) dan key service_role. Keduanya adalah JSON Web Token yang ditandatangani oleh JWT secret proyek Anda. Perbedaannya adalah claim role yang dipanggang ke dalam payload JWT — anon untuk key publik, service_role untuk kunci master. PostgREST, Supabase Storage, dan Supabase Auth semuanya beralih ke mode bypass-segalanya ketika mereka melihat claim service_role.

Decode key Supabase apa pun di jwt.io dan lihat payload-nya. Bentuk JWT service-role tidak salah lagi:

Payload yang ter-decode dari JWT service-role (ditampilkan sebagai blok dengan syntax highlight di bawah).

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

Proyek Supabase yang lebih baru menerbitkan key bergaya rahasia dengan prefix sb_secret_ alih-alih JWT. Perilakunya identik — apa pun yang membawa sb_secret_ di bundle publik sama-sama katastrofis.

Bagaimana AI coding tools membocorkan service role key

Kami telah melihat tiga pola yang sama di ribuan aplikasi vibe-coded. Masing-masing dimulai dengan pengembang meminta bantuan AI tool dan berakhir dengan service key ter-inline ke dalam bundle.

Pola 1: File .env tunggal dengan prefix NEXT_PUBLIC_

Pengembang meminta AI tool untuk "menyiapkan Supabase" dan menerima satu .env dengan kedua key. AI tool — dilatih pada korpus di mana sebagian besar environment variable diekspos via NEXT_PUBLIC_* — memberi prefix NEXT_PUBLIC_ pada keduanya. Next.js meng-inline apa pun yang cocok dengan prefix itu ke dalam bundle klien pada build time. Kirim ke Vercel, dan service key ada di main.[hash].js.

Pola 2: Key salah dalam panggilan createClient

Pengembang menempelkan kedua key ke file config.ts yang dihasilkan AI, dan AI mengisi panggilan createClient() sisi browser dengan process.env.SUPABASE_SERVICE_ROLE_KEY karena keliru. Build menarik variabel itu, dan JWT mendarat di bundle.

Pola 3: Service role key di-hardcode di skrip seed

Pengembang meminta AI tool untuk menulis skrip yang men-seed database. AI meng-hardcode service role key langsung ke dalam file (alih-alih membaca dari environment), commit file ke repositori, dan repo GitHub publik atau route /scripts/seed.js aplikasi yang ter-deploy sekarang menyajikan key.

Cara scan bundle FixVibe mendeteksi kebocoran

Check bundle-secrets FixVibe mengunduh setiap file JavaScript yang direferensikan oleh aplikasi yang ter-deploy — entry chunk, lazy-loaded chunk, web worker, service worker — dan menjalankannya melalui detektor yang men-decode apa pun yang cocok dengan bentuk JWT (eyJ[base64-header].eyJ[base64-payload].[signature]). Jika payload yang ter-decode berisi "role": "service_role", scan melaporkannya sebagai temuan kritis dengan path file dan baris persis di mana key muncul. Check yang sama juga mencocokkan pola sb_secret_* yang lebih baru berdasarkan prefix.

Scan tidak pernah berautentikasi dengan key yang ditemukan. Ia mengidentifikasi bentuk dan melaporkan kebocoran — menggunakan key untuk membuktikan eksploitabilitas akan menjadi akses tidak sah ke database Anda. Buktinya ada di payload JWT itu sendiri.

Terdeteksi — apa yang harus dilakukan di jam pertama

Service role key yang bocor adalah keadaan darurat runtime. Asumsikan key telah di-scrape — penyerang memantau bundle publik secara real time. Perlakukan database sebagai terkompromi sampai Anda telah merotasi key dan mengaudit aktivitas terkini.

1. Rotasi key segera. Di Dashboard Supabase, masuk ke Project Settings → API → Service role key → Reset. Key lama diinvalidasi dalam hitungan detik. Setiap kode sisi server yang menggunakan key harus diperbarui dan di-deploy ulang sebelum rotasi mendarat.
2. Audit aktivitas database terkini. Buka Database → Logs di dashboard. Filter pada 7 hari terakhir. Cari query SELECT * tidak biasa terhadap tabel dengan PII, statement UPDATE atau DELETE besar, dan request dari IP di luar infrastruktur yang Anda kenal. Supabase mencatat header x-real-ip pada setiap request.
3. Periksa objek storage. Kunjungi Storage → Logs dan tinjau unduhan file terkini. Service role key yang bocor memberikan akses bypass-segalanya ke bucket privat juga.
4. Hapus key dari source control. Bahkan setelah rotasi, meninggalkan JWT di history git Anda berarti ia dapat ditemukan di repo publik. Gunakan git filter-repo atau BFG Repo-Cleaner untuk membersihkannya dari history, kemudian force-push (peringatkan kolaborator terlebih dahulu).
5. Scan ulang setelah perbaikan. Jalankan scan FixVibe baru terhadap aplikasi yang di-deploy ulang. Temuan bundle-secrets seharusnya hilang. Konfirmasi tidak ada JWT service_role dan tidak ada string sb_secret_* yang tersisa di chunk mana pun.

Mencegah kebocoran sejak awal

Perbaikan struktural adalah disiplin penamaan ditambah pengaman di tingkat tool:

• Jangan pernah memberi prefix service key dengan NEXT_PUBLIC_*, VITE_*, atau prefix bundle-inlining lainnya. Konvensi penamaan adalah batasnya — setiap framework menghormatinya.
• Jauhkan service key sepenuhnya dari .env di mesin pengembang. Baca dari secret manager (Doppler, Infisical, env vars terenkripsi Vercel) saat deploy, jangan pernah commit secara lokal.
• <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.
• Tambahkan gate CI yang men-scan output build. Setelah next build, grep output .next/static/chunks/ untuk string service_role. Gagalkan build jika ada yang cocok.

# 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

Pertanyaan yang sering diajukan

Langkah berikutnya

Jalankan scan FixVibe terhadap URL produksi Anda — check bundle-secrets gratis, tanpa pendaftaran, dan melaporkan eksposur service_role dalam waktu kurang dari semenit. Pasangkan ini dengan artikel Scanner RLS Supabase untuk memverifikasi lapisan RLS bekerja dengan baik, dan Checklist keamanan bucket storage Supabase untuk mengunci akses file. Untuk latar belakang mengapa AI tools menghasilkan kelas kebocoran ini dengan begitu andal, baca Mengapa AI coding tools meninggalkan celah keamanan.