Supabase service role key JavaScript માં ઉજાગર: તેનો અર્થ શું છે અને તેને કેવી રીતે શોધવી

Service role key શું છે

Supabase દરેક project માટે બે અલગ keys ઈશ્યુ કરે છે: anon key (નવા projects માં publishable key પણ કહેવાય છે) અને service_role key. બંને તમારા project ની JWT secret દ્વારા signed JSON Web Tokens છે. તફાવત JWT payload માં બેક કરેલા role claim નો છે — public key માટે anon, master key માટે service_role. PostgREST, Supabase Storage, અને Supabase Auth બધા જ્યારે service_role claim જુએ ત્યારે bypass-everything mode માં બદલાય છે.

કોઈપણ Supabase key ને jwt.io પર decode કરો અને payload જુઓ. Service-role JWT નો shape અસ્પષ્ટ નથી:

Service-role JWT ની decoded payload (નીચે syntax-highlighted block તરીકે બતાવેલ).

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

નવા Supabase projects JWT ને બદલે sb_secret_ prefix સાથે secret-style keys ઈશ્યુ કરે છે. વર્તન સમાન છે — public bundle માં sb_secret_ ધરાવતું કંઈપણ સમાન રીતે વિનાશક છે.

AI કોડિંગ ટૂલ service role key કેવી રીતે leak કરે છે

અમે હજારો vibe-coded apps માં એ જ ત્રણ patterns જોયા છે. દરેક developer ના AI ટૂલ ને મદદ માટે પૂછવાથી શરૂ થાય છે અને service key bundle માં inlined થવા સાથે સમાપ્ત થાય છે.

Pattern 1: NEXT_PUBLIC_ prefix સાથે એક જ .env file

Developer AI ટૂલ ને "Supabase set up કરો" પૂછે છે અને બંને keys સાથે એક .env સ્વીકારે છે. AI ટૂલ — એક corpus પર trained જ્યાં મોટાભાગના environment variables NEXT_PUBLIC_* દ્વારા expose થાય છે — બંને ને NEXT_PUBLIC_ prefix કરે છે. Next.js એ prefix સાથે મેળ ખાતી કોઈપણ વસ્તુ ને build time પર client bundle માં inline કરે છે. Vercel પર ship કરો, અને service key main.[hash].js માં છે.

Pattern 2: createClient call માં ખોટી key

Developer AI દ્વારા generated config.ts file માં બંને keys paste કરે છે, અને AI browser-side createClient() call ને ભૂલથી process.env.SUPABASE_SERVICE_ROLE_KEY સાથે populate કરે છે. Build variable ને pull કરે છે, અને JWT bundle માં લેન્ડ થાય છે.

Pattern 3: Service-role key seed scripts માં hardcoded

Developer AI ટૂલ ને એક script લખવા પૂછે છે જે database ને seed કરે છે. AI service-role key ને file માં સીધી hardcode કરે છે (environment માંથી વાંચવાને બદલે), file ને repository માં commit કરે છે, અને public GitHub repo અથવા deployed app નો /scripts/seed.js route હવે key serve કરી રહ્યો છે.

FixVibe bundle scan leak ને કેવી રીતે detect કરે છે

FixVibe ની bundle-secrets check deployed app દ્વારા referenced દરેક JavaScript file download કરે છે — entry chunks, lazy-loaded chunks, web workers, service workers — અને તેમને એક detector મારફતે ચલાવે છે જે JWT shape (eyJ[base64-header].eyJ[base64-payload].[signature]) સાથે મેળ ખાતી કોઈપણ વસ્તુ ને decode કરે છે. જો decoded payload માં "role": "service_role" હોય, તો scan તેને file path અને key જ્યાં દેખાય તે ચોક્કસ line સાથે critical finding તરીકે report કરે છે. એ જ check નવા sb_secret_* pattern સાથે prefix દ્વારા પણ મેળ ખાય છે.

Scan ક્યારેય discovered key સાથે authenticate નથી થતું. તે shape ઓળખે છે અને leak report કરે છે — exploitability સાબિત કરવા key નો ઉપયોગ કરવો એ તમારા database ની અનધિકૃત access હશે. પુરાવો JWT payload માં જ છે.

Detect થયું — પ્રથમ કલાકમાં શું કરવું

Leak થયેલી service role key એક runtime કટોકટી છે. ધારો કે key scrape કરી લેવામાં આવી છે — હુમલાખોરો real time માં public bundles ને monitor કરે છે. જ્યાં સુધી તમે key ને rotate કરી લો અને તાજેતરની activity નું audit કરી લો ત્યાં સુધી database ને compromise થયેલું ગણો.

1. Key ને તરત rotate કરો. Supabase Dashboard માં, Project Settings → API → Service role key → Reset પર જાઓ. જૂની key સેકન્ડ્સ ની અંદર invalidate થાય છે. Key નો ઉપયોગ કરતો કોઈપણ service-side code rotation લેન્ડ થાય તે પહેલા update અને redeployed થવો જોઈએ.
2. તાજેતરની database activity નું audit કરો. Dashboard માં Database → Logs ખોલો. છેલ્લા 7 દિવસ પર filter કરો. PII ધરાવતી tables સામે અસામાન્ય SELECT * queries, મોટા UPDATE અથવા DELETE statements, અને તમારી જાણીતી infrastructure ની બહારના IPs માંથી requests શોધો. Supabase દરેક request પર x-real-ip header log કરે છે.
3. Storage objects check કરો. Storage → Logs ની મુલાકાત લો અને તાજેતરના file downloads ની સમીક્ષા કરો. Leak થયેલી service-role key private buckets ને પણ bypass-everything access આપે છે.
4. Source control માંથી key દૂર કરો. Rotation પછી પણ, તમારી git history માં JWT છોડવાનો અર્થ છે કે તે public repo માં discoverable છે. History માંથી તેને scrub કરવા માટે git filter-repo અથવા BFG Repo-Cleaner નો ઉપયોગ કરો, પછી force-push કરો (પ્રથમ collaborators ને ચેતવણી આપો).
5. Fix પછી ફરી scan કરો. Redeployed app સામે તાજો FixVibe scan ચલાવો. Bundle-secrets finding clear થવી જોઈએ. Confirm કરો કે કોઈ chunk માં service_role JWT અને કોઈ sb_secret_* string બાકી નથી.

પ્રથમ સ્થાને leak ને રોકવો

Structural fix નામકરણ શિસ્ત વત્તા ટૂલ-લેવલ guardrails છે:

• Service key ને ક્યારેય NEXT_PUBLIC_*, VITE_*, અથવા કોઈ બીજા bundle-inlining prefix સાથે prefix ન કરો. નામકરણ સંમેલન સીમા છે — દરેક framework તેને માન આપે છે.
• Developer machine પર .env માંથી service key ને સંપૂર્ણપણે બહાર રાખો. Deploy પર secret manager (Doppler, Infisical, Vercel encrypted env vars) માંથી તેને વાંચો, ક્યારેય locally commit ન કરો.
• <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.
• એક CI gate ઉમેરો જે build output ને scan કરે. next build પછી, .next/static/chunks/ output માં service_role string માટે grep કરો. જો કંઈ મેળ ખાય તો build fail કરો.

# 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

વારંવાર પૂછાતા પ્રશ્નો

આગળના પગલાં

તમારા production URL સામે FixVibe scan ચલાવો — bundle-secrets check મફત છે, કોઈ signup નહીં, અને એક મિનિટ કરતા ઓછા સમયમાં service_role exposure report કરે છે. RLS layer કામ કરી રહ્યું છે કે કેમ તે verify કરવા આને Supabase RLS scanner લેખ સાથે અને file access ને lock down કરવા Supabase storage bucket security checklist સાથે pair કરો. AI ટૂલ આ leak class ને આટલી વિશ્વસનીય રીતે કેમ generate કરે છે તેની background માટે, AI કોડિંગ ટૂલ security gaps કેમ છોડે છે વાંચો.