מפתח Supabase service role חשוף ב-JavaScript: מה זה אומר ואיך למצוא אותו

מה זה מפתח ה-service role

Supabase מנפיק שני מפתחות שונים לכל פרויקט: מפתח anon (שנקרא גם מפתח publishable בפרויקטים חדשים יותר) ומפתח service_role. שניהם JSON Web Tokens החתומים בסוד ה-JWT של הפרויקט שלך. ההבדל הוא ה-claim role שאפוי בתוך payload ה-JWT — anon עבור המפתח הציבורי, service_role עבור המפתח הראשי. PostgREST, Supabase Storage ו-Supabase Auth כולם עוברים למצב עקיפה-של-הכל כשהם רואים את ה-claim service_role.

פענח כל מפתח Supabase ב-jwt.io והסתכל על ה-payload. צורת JWT של service-role היא בלתי ניתנת לטעות:

Payload מפוענח של JWT service-role (מוצג כבלוק עם הדגשת תחביר מטה).

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

פרויקטי Supabase חדשים יותר מנפיקים מפתחות בסגנון secret עם הקידומת sb_secret_ במקום JWT. ההתנהגות זהה — כל דבר שנושא sb_secret_ בחבילה ציבורית הוא קטסטרופלי באותה מידה.

איך כלי קוד מבוססי-AI מדליפים את מפתח ה-service role

ראינו את אותם שלושה דפוסים על פני אלפי אפליקציות vibe-coded. כל אחד מתחיל במפתח שמבקש מכלי AI עזרה ומסתיים במפתח ה-service מוטמע בתוך חבילה.

דפוס 1: קובץ .env יחיד עם קידומת NEXT_PUBLIC_

המפתח מבקש מכלי ה-AI "להגדיר Supabase" ומקבל .env יחיד עם שני המפתחות. כלי ה-AI — שאומן על קורפוס שבו רוב משתני הסביבה נחשפים דרך NEXT_PUBLIC_* — מקדים את שניהם ב-NEXT_PUBLIC_. Next.js מטמיעה כל דבר שתואם לקידומת הזו לחבילת הלקוח בזמן build. שולחים ל-Vercel, ומפתח ה-service נמצא ב-main.[hash].js.

דפוס 2: מפתח שגוי בקריאת createClient

המפתח מדביק את שני המפתחות לקובץ config.ts שה-AI יצר, וה-AI מאכלס את קריאת ה-createClient() שצד-הדפדפן ב-process.env.SUPABASE_SERVICE_ROLE_KEY בטעות. ה-build מושך את המשתנה פנימה, וה-JWT נוחת בחבילה.

דפוס 3: מפתח service-role מוטמע בקוד בתסריטי seed

המפתח מבקש מכלי ה-AI לכתוב תסריט שמזין נתונים למסד הנתונים. ה-AI מוטמע את מפתח ה-service-role ישירות לתוך הקובץ (במקום לקרוא מהסביבה), מבצע commit לקובץ למאגר, ומאגר ה-GitHub הציבורי או נתיב /scripts/seed.js של האפליקציה המותקנת משרת כעת את המפתח.

איך סריקת החבילה של FixVibe מזהה את הדלף

בדיקת bundle-secrets של FixVibe מורידה כל קובץ JavaScript שהאפליקציה המותקנת מפנה אליו — chunks של entry, chunks הנטענים בעצלות, web workers, service workers — ומריצה אותם דרך זיהוי שמפענח כל דבר שתואם לצורת JWT (eyJ[base64-header].eyJ[base64-payload].[signature]). אם ה-payload המפוענח מכיל "role": "service_role", הסריקה מדווחת זאת כממצא קריטי עם נתיב הקובץ והשורה המדויקת שבה מופיע המפתח. אותה בדיקה גם תואמת את הדפוס החדש יותר sb_secret_* לפי קידומת.

הסריקה לעולם לא מתאמתת עם המפתח שהתגלה. היא מזהה את הצורה ומדווחת על הדלף — שימוש במפתח כדי להוכיח ניצולת היה גישה לא-מורשית למסד הנתונים שלך. ההוכחה נמצאת ב-payload של ה-JWT עצמו.

התגלה — מה לעשות בשעה הראשונה

מפתח service role שדלף הוא חירום runtime. הנח שהמפתח גרוף — תוקפים מנטרים חבילות ציבוריות בזמן אמת. התייחס למסד הנתונים כאל פרוץ עד שתסבב את המפתח ותבצע audit לפעילות האחרונה.

1. סבב את המפתח מיד. ב-Dashboard של Supabase, עבור ל-Project Settings → API → Service role key → Reset. המפתח הישן מבוטל תוך שניות. כל קוד צד-שרת שמשתמש במפתח חייב להתעדכן ולהיפרס מחדש לפני שהסבב נכנס לתוקף.
2. בצע audit לפעילות מסד הנתונים האחרונה. פתח Database → Logs ב-dashboard. סנן ל-7 הימים האחרונים. חפש שאילתות SELECT * חריגות מול טבלאות עם PII, הצהרות UPDATE או DELETE גדולות, ובקשות מ-IPs מחוץ לתשתית הידועה שלך. Supabase מתעד את header ה-x-real-ip בכל בקשה.
3. בדוק אובייקטים של אחסון. בקר ב-Storage → Logs וסקור הורדות קבצים אחרונות. מפתח service-role שדלף מעניק גישה של עקיפה-של-הכל גם לדליים פרטיים.
4. הסר את המפתח מבקרת המקור. אפילו אחרי סבב, השארת ה-JWT בהיסטוריית ה-git שלך אומרת שהוא ניתן לגילוי במאגר הציבורי. השתמש ב-git filter-repo או ב-BFG Repo-Cleaner כדי לקרצף אותו מההיסטוריה, ואז בצע force-push (הזהר משתפי פעולה תחילה).
5. סרוק מחדש אחרי התיקון. הרץ סריקת FixVibe חדשה מול האפליקציה הפרוסה מחדש. ממצא ה-bundle-secrets אמור להיעלם. אשר שאין JWT של service_role ושאין מחרוזת sb_secret_* בכל chunk.

מניעת הדלף מלכתחילה

הפתרון המבני הוא משמעת בשמות פלוס מעקות בטיחות ברמת הכלי:

• לעולם אל תקדים את מפתח ה-service ב-NEXT_PUBLIC_*, VITE_*, או כל קידומת אחרת של הטמעה בחבילה. מוסכמת השמות היא הגבול — כל פריימוורק מכבד אותה.
• שמור את מפתח ה-service לחלוטין מחוץ ל-.env במכונת המפתח. קרא אותו ממנהל סודות (Doppler, Infisical, משתני סביבה מוצפנים של Vercel) בזמן 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 שסורק את פלט ה-build. אחרי next build, חפש בפלט .next/static/chunks/ את המחרוזת 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 מול URL הייצור שלך — בדיקת ה-bundle-secrets חינמית, ללא הרשמה, ומדווחת על חשיפת service_role תוך פחות מדקה. צמד את זה עם המאמר סורק Supabase RLS כדי לאמת ששכבת ה-RLS עושה את עבודתה, ועם רשימת בדיקה לאבטחת דליי אחסון של Supabase כדי לנעול את הגישה לקבצים. לרקע על מדוע כלי AI מייצרים את מחלקת הדלף הזו באמינות כזו, קרא מדוע כלי קוד מבוססי-AI משאירים פערי אבטחה.