Supabase service role key ត្រូវបានបង្ហាញនៅក្នុង JavaScript៖ មានន័យដូចម្ដេច និងរបៀបរកឃើញវា

តើ service role key គឺជាអ្វី

Supabase ចេញ key ផ្សេងគ្នាពីរសម្រាប់រាល់ project៖ anon key (ហៅផងដែរថា publishable key នៅក្នុង project ថ្មីៗ) និង service_role key។ ទាំងពីរគឺជា JSON Web Token ដែលចុះហត្ថលេខាដោយ JWT secret នៃ project របស់អ្នក។ ភាពខុសគ្នាគឺ claim role នៅក្នុង payload JWT — anon សម្រាប់ key សាធារណៈ, service_role សម្រាប់ master key។ PostgREST, Supabase Storage និង Supabase Auth ទាំងអស់ប្ដូរទៅ mode រំលងគ្រប់យ៉ាងនៅពេលពួកវាឃើញ claim service_role។

Decode Supabase key ណាមួយនៅ jwt.io ហើយមើល payload។ រូបរាងនៃ JWT service-role គឺច្បាស់៖

Decoded payload នៃ JWT service-role (បង្ហាញជា syntax-highlighted block ខាងក្រោម)។

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

Supabase project ថ្មីៗបញ្ចេញ key រូបបែប secret ជាមួយ prefix sb_secret_ ជំនួសឱ្យ JWT។ ឥរិយាបថដូចគ្នា — អ្វីដែលផ្ទុក sb_secret_ នៅក្នុង bundle សាធារណៈគឺមហន្តរាយដូចគ្នា។

របៀបដែលឧបករណ៍សរសេរកូដ AI ធ្វើឱ្យ service role key លេចធ្លាយ

យើងបានឃើញលំនាំបីដូចគ្នានៅទូទាំងកម្មវិធី vibe-coded រាប់ពាន់។ មួយៗចាប់ផ្ដើមជាមួយអ្នកអភិវឌ្ឍន៍សួរឧបករណ៍ AI សម្រាប់ជំនួយ ហើយបញ្ចប់ដោយ service key inline ទៅក្នុង bundle។

លំនាំទី 1៖ ឯកសារ .env តែមួយជាមួយ prefix NEXT_PUBLIC_

អ្នកអភិវឌ្ឍន៍សួរឧបករណ៍ AI ឱ្យ "set up Supabase" ហើយទទួលយក .env តែមួយជាមួយ key ទាំងពីរ។ ឧបករណ៍ AI — ដែលត្រូវបានបង្វឹកលើ corpus ដែលរាល់ environment variable ត្រូវបានបង្ហាញតាមរយៈ NEXT_PUBLIC_* — បន្ថែម prefix ទាំងពីរជាមួយ NEXT_PUBLIC_។ Next.js inline អ្វីដែលត្រូវនឹង prefix នោះទៅក្នុង client bundle នៅពេល build។ Deploy ទៅ Vercel ហើយ service key ស្ថិតក្នុង main.[hash].js។

លំនាំទី 2៖ Key ខុសក្នុងការហៅ createClient

អ្នកអភិវឌ្ឍន៍បិទភ្ជាប់ key ទាំងពីរទៅក្នុងឯកសារ config.ts ដែល AI បានបង្កើត ហើយ AI បំពេញការហៅ createClient() browser-side ជាមួយ process.env.SUPABASE_SERVICE_ROLE_KEY ដោយកំហុស។ Build ទាញ variable ចូល ហើយ JWT ធ្លាក់ទៅក្នុង bundle។

លំនាំទី 3៖ Service-role key hardcoded ក្នុង seed script

អ្នកអភិវឌ្ឍន៍សួរឧបករណ៍ AI ឱ្យសរសេរ script ដែល seed database។ AI hardcode service-role key ដោយផ្ទាល់ទៅក្នុងឯកសារ (ជំនួសឱ្យការអានពី environment), commit ឯកសារទៅ repository ហើយ repo GitHub សាធារណៈ ឬផ្លូវ /scripts/seed.js នៃកម្មវិធីដែលបាន deploy ឥឡូវនេះបម្រើ key។

របៀបដែល FixVibe bundle scan រកឃើញការលេចធ្លាយ

ការត្រួតពិនិត្យ bundle-secrets របស់ FixVibe ទាញយករាល់ឯកសារ JavaScript ដែលយោងដោយកម្មវិធីដែលបាន deploy — entry chunks, lazy-loaded chunks, web workers, service workers — ហើយដំណើរការពួកវាតាមរយៈ detector ដែល decode អ្វីដែលត្រូវនឹងរូបរាង JWT (eyJ[base64-header].eyJ[base64-payload].[signature])។ បើ payload decoded មាន "role": "service_role", scan រាយការណ៍ថាជា finding critical ជាមួយផ្លូវឯកសារ និងបន្ទាត់ពិតប្រាកដដែល key លេចឡើង។ ការត្រួតពិនិត្យដូចគ្នាក៏ត្រូវនឹងលំនាំ sb_secret_* ថ្មីដោយ prefix ផងដែរ។

Scan មិនដែល authenticate ជាមួយ key ដែលរកឃើញឡើយ។ វាកំណត់រូបរាង និងរាយការណ៍ការលេចធ្លាយ — ការប្រើ key ដើម្បីបញ្ជាក់ការអាចកេងប្រវ័ញ្ចនឹងជាការចូលប្រើដែលគ្មានការអនុញ្ញាតទៅកាន់ database របស់អ្នក។ ភស្ដុតាងស្ថិតនៅក្នុង payload JWT ខ្លួនវាផ្ទាល់។

រកឃើញហើយ — អ្វីដែលត្រូវធ្វើនៅម៉ោងដំបូង

Service role key ដែលលេចធ្លាយគឺជាគ្រោះមហន្តរាយ runtime។ សន្មត់ថា key ត្រូវបានកេងយក — អ្នកវាយប្រហារតាមដាន bundle សាធារណៈជា real time។ ចាត់ទុក database ថាត្រូវបានសម្របសម្រួលរហូតដល់អ្នកបានបង្វិល key និងត្រួតពិនិត្យសកម្មភាពថ្មីៗ។

1. បង្វិល key ភ្លាមៗ។ នៅក្នុង Supabase Dashboard, ទៅកាន់ Project Settings → API → Service role key → Reset។ Key ចាស់ត្រូវបានបដិសេធក្នុងរយៈពេលប៉ុន្មានវិនាទី។ កូដ service-side ដែលប្រើ key ត្រូវធ្វើបច្ចុប្បន្នភាព និង redeploy មុនពេលការ rotate ធ្លាក់។
2. ត្រួតពិនិត្យសកម្មភាព database ថ្មីៗ។ បើក Database → Logs នៅក្នុង dashboard។ ត្រងលើ 7 ថ្ងៃចុងក្រោយ។ មើល query SELECT * មិនធម្មតាប្រឆាំងនឹងតារាងជាមួយ PII, statement UPDATE ឬ DELETE ធំ និង request ពី IP ខាងក្រៅហេដ្ឋារចនាសម្ព័ន្ធដែលអ្នកស្គាល់។ Supabase log header x-real-ip លើរាល់ request។
3. ត្រួតពិនិត្យ storage object។ ទស្សនា Storage → Logs ហើយពិនិត្យការទាញយកឯកសារថ្មីៗ។ Service-role key ដែលលេចធ្លាយផ្ដល់ការចូលប្រើរំលងគ្រប់យ៉ាងទៅ bucket ឯកជនផងដែរ។
4. លុប key ចេញពី source control។ សូម្បីបន្ទាប់ពីការ rotate, ការទុក JWT នៅក្នុងប្រវត្តិ git របស់អ្នកមានន័យថាវាអាចរកឃើញនៅក្នុង repo សាធារណៈ។ ប្រើ git filter-repo ឬ BFG Repo-Cleaner ដើម្បីសម្អាតវាចេញពីប្រវត្តិ បន្ទាប់មក force-push (ព្រមាន collaborator មុន)។
5. Scan ឡើងវិញបន្ទាប់ពីការជួសជុល។ ដំណើរការ FixVibe scan ស្រស់ប្រឆាំងនឹងកម្មវិធីដែលបាន redeploy។ Finding bundle-secrets គួរត្រូវលុបបំបាត់។ បញ្ជាក់ថាគ្មាន JWT service_role និងគ្មាន string sb_secret_* នៅក្នុង chunk ណាមួយឡើយ។

ការការពារការលេចធ្លាយតាំងពីដំបូង

ដំណោះស្រាយរចនាសម្ព័ន្ធគឺវិន័យក្នុងការដាក់ឈ្មោះបូកនឹង guardrail កម្រិតឧបករណ៍៖

• មិនត្រូវដាក់ prefix service key ជាមួយ NEXT_PUBLIC_*, VITE_* ឬ prefix bundle-inlining ផ្សេងទៀតឡើយ។ អនុសញ្ញាដាក់ឈ្មោះគឺជាព្រំដែន — រាល់ framework គោរពវា។
• ទុក service key ឱ្យចេញពី .env ទាំងស្រុងនៅលើ developer machine។ អានវាពី secret manager (Doppler, Infisical, Vercel encrypted env vars) នៅពេល deploy, កុំ 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 ដែល scan build output។ បន្ទាប់ពី next build, grep .next/static/chunks/ output សម្រាប់ string service_role។ បរាជ័យ build បើមានអ្វីត្រូវនឹង។

# 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

សំណួរសួរញឹកញាប់

ជំហានបន្ទាប់

ដំណើរការ FixVibe scan ប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក — ការត្រួតពិនិត្យ bundle-secrets គឺឥតគិតថ្លៃ, គ្មានការចុះឈ្មោះ ហើយរាយការណ៍ការបង្ហាញ service_role ក្នុងរយៈពេលក្រោម 1 នាទី។ ផ្គូជាមួយអត្ថបទ Supabase RLS scanner ដើម្បីផ្ទៀងផ្ទាត់ថា layer RLS កំពុងធ្វើការងាររបស់វា និង បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Supabase storage bucket ដើម្បីចាក់សោការចូលប្រើឯកសារ។ សម្រាប់ផ្ទៃខាងក្រោយអំពីហេតុអ្វីឧបករណ៍ AI បង្កើតថ្នាក់លេចធ្លាយនេះដោយជឿជាក់, សូមអាន ហេតុអ្វីឧបករណ៍សរសេរកូដ AI ទុកគម្លាតសុវត្ថិភាព។