// docs / baas security / auth0 hardening

רשימת בדיקה לאבטחת Auth0: 22 פריטים

Auth0 היא פלטפורמת identity-as-a-service עם משטח ענק — אפליקציות, APIs (resource servers), דיירים, actions, rules (legacy), connections, ו-grants. תצורה שגויה של כל אחד מהם היא עקיפת אימות. הרשימה הזו היא audit של 22 פריטים על פני אפליקציות, רשימות היתר של callback / logout, טוקנים וסבב refresh, custom actions, RBAC, זיהוי אנומליות, וניטור שוטף. כל פריט ניתן לאימות ב-Dashboard של Auth0 תוך פחות מ-10 דקות.

לרשימת הבדיקה המקבילה ב-Clerk, ראה רשימת בדיקה לאבטחת Clerk. לרקע על מדוע תצורות שגויות של שכבת זהויות הן נקודות עיוורות של כלי AI, ראה מדוע כלי קוד מבוססי-AI משאירים פערי אבטחה.

סוג אפליקציה וסוגי grant

סוג האפליקציה וסוגי ה-grant המופעלים הם ההגדרות בעלות ההשפעה הגבוהה ביותר ב-Auth0. טעות בהם פותחת מחלקות התקפה ששום כמות של קוד frontend לא תסגור.

השתמש ב-Application Type = Single Page Application עבור אפליקציות דפדפן-בלבד וב-Regular Web Application עבור אפליקציות מרונדרות-בשרת. הסוג הלא נכון מתיר את סוגי ה-grant הלא נכונים — למשל, Regular Web App עם grant של SPA מאפשר זרימת Implicit ללא-PKCE, שמדליפה טוקנים דרך URL fragments.
השבת את סוג ה-grant Implicit על כל אפליקציה. Dashboard → Application → Advanced Settings → Grant Types → בטל סימון של Implicit. זרימת Implicit מחזירה טוקנים ב-URL fragments, שם הם מתועדים בהיסטוריית הדפדפן ובאנליטיקס. השתמש ב-Authorization Code עם PKCE במקום.
השבת grant של Password אלא אם יש לך צורך מתועד. grant של Resource Owner Password Credentials (ROPC) דורש שתטפל בסיסמאות משתמש בעצמך — מבטל את רוב מה שקנית את Auth0 בשבילו. השבת אותו אלא אם אתה משלב מערכת מדור קודם.
הפעל Authorization Code עם PKCE על כל לקוח ציבורי. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled. PKCE נדרש עבור אפליקציות נייד ו-SPAs כדי למנוע יירוט קוד.

רשימות היתר של callback ו-logout URL

Open redirects על נתיב ה-callback של OAuth הם פרימיטיב לגניבת טוקן. רשימת ההיתר של Auth0 היא ההגנה היחידה שלך.

הגדר את Allowed Callback URLs לנתיב ה-callback המדויק של הייצור שלך — ללא wildcards. https://yourapp.com/callback, לא https://yourapp.com/*. callbacks עם wildcard מאפשרים לתוקפים להפנות טוקנים לנתיבי משנה שרירותיים בדומיין שלך.
הגדר את Allowed Logout URLs לרשימה סופית. אותו כלל: URLs מפורשים בלבד. הפניית logout פתוחה מאפשרת לתוקפים ליצור דפי דיוג שנראים כמו מצב הפוסט-logout שלך.
הגדר את Allowed Web Origins למקור הייצור שלך בלבד. משמש לאימות שקט (חידוש טוקן דרך iframe מוסתר). מקור wildcard מאפשר לדפי תוקף לבצע אימות שקט מול הדייר שלך.
הגדר Allowed CORS origins עבור נקודות הקצה של ה-API, לא של האפליקציה. Tenant Settings → Advanced → Allowed CORS origins. ברירת המחדל ריקה (מוגבל); הוסף רק מקורות מפורשים שאתה שולט בהם.

טוקנים וסבב refresh

אורך חיי טוקן, סבב refresh, ואלגוריתם חתימה מחליטים על רדיוס הפיצוץ של כל הדלפת טוקן.

הפעל Refresh Token Rotation. Application → Refresh Token Settings → Rotation. כל refresh מנפיק refresh token חדש ומבטל את הישן. בשילוב עם תפוגה מוחלטת, זה מכיל גניבת טוקן.
הגדר Refresh Token Reuse Interval ל-0 (או נמוך ככל שסבילות ה-replay שלך מאפשרת). ה-reuse interval מתיר לטוקן להיות בשימוש פעמיים באותו חלון — כבה אותו אלא אם יש לך סיבה ספציפית לשמור אותו.
הגדר Absolute Refresh Token Expiry ל-14-30 ימים, לא אינסוף. Application → Refresh Token Expiration → Absolute Expiration. Auth0 כברירת מחדל הוא Inactivity-בלבד, מה שאומר ש-session סרק יכול להימשך שנים.
הגדר JWT Signature Algorithm ל-RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 משתמש בחתימה אסימטרית כך שהלקוח לא יכול לזייף טוקנים. לעולם אל תשתמש ב-HS256 עבור אפליקציות מול-לקוח.
אמת claims של aud ו-iss על כל JWT שה-API שלך מקבל. השתמש ב-SDK הרשמי של Auth0 בצד-שרת — הוא מאמת את אלה אוטומטית. ניתוח JWT בעבודת-יד בדרך כלל מדלג על אימות audience, שזו עקיפת אימות.

Actions וקוד מותאם

Auth0 Actions (ו-Rules ישנים יותר) רצים בצד-שרת בכניסה ובאירועי מחזור-חיים אחרים. יש להם גישה להקשר הבקשה כולו. קוד לא-בטוח כאן הוא פגיעות ברמת-דייר.

לעולם אל תתעד את event.user או event.transaction כאובייקט שלם. אלה מכילים כתובות אימייל, כתובות IP, ו-PII אחר. השתמש בתיעוד ברמת שדה בלבד, ותעד רק את מה שאתה צריך.
השתמש במאגר הסודות עבור כל מפתח API או URL של webhook. Actions → Edit → Secrets. לעולם אל תטמיע מפתח API כליטרל מחרוזת בקוד action — הקוד גלוי לכל מי שיש לו גישת עריכת Action בדייר.
אמת קלטים לפני שמירתם כ-user_metadata או app_metadata. action של שירות-עצמי שכותב event.body.name ל-user.user_metadata.display_name הוא וקטור XSS מאוחסן אם ה-frontend שלך מציג את השדה הזה ללא escaping.

RBAC ו-resource servers

אם אתה משתמש ב-Auth0 RBAC, מיפוי תפקיד-להרשאה הוא שכבת ההרשאה שלך. טעות בו וכל משתמש מאומת יכול להגיע לנקודות קצה של admin.

הגדר Resource Servers (APIs) במפורש ב-Dashboard של Auth0, לא בזמן ריצה. לכל API יש מזהה (ה-audience), scopes, והגדרות חתימה. ללא API רשום, כל הטוקנים מונפקים עבור ה-"Auth0 Management API" המשתמע — audience שגוי.
הגדר Permissions לכל API ודרוש אותן בקוד שלך עם ה-claim scope. אל תבדוק חברות בתפקיד בלוגיקת האפליקציה שלך; בדוק scopes בטוקן הגישה. Scopes הם מנגנון ההרשאה המקורי של OAuth.
בדוק שמשתמש מאומת ללא התפקיד / scope הנדרש לא יכול להגיע לנקודות קצה מועדפות. היכנס כמשתמש רגיל, נסה לקרוא ל-POST /api/admin/users/delete. התגובה חייבת להיות 403.

זיהוי אנומליות ויומני דייר

Auth0 שולח אירועים בעלי-אות-גבוה. הגדר אותם להתרעה לצוות שלך, לא רק לשבת במאגר יומן.

הפעל Attack Protection: Bot Detection, Brute Force, Suspicious IP Throttling. Dashboard → Security → Attack Protection. כל אחד מושבת כברירת מחדל ברמות חינמיות; הפעל את כולם לייצור.
הזרם יומני דייר ל-SIEM או ליומני האפליקציה שלך. Dashboard → Monitoring → Streams. Auth0 שומר יומנים ל-30 ימים ברוב התוכניות; שמירה ארוכת-טווח דורשת זרם למערכת שלך.
התרע על קפיצות של fcoa (אימות חוצה-מקור כושל) ו-fp (כניסה כושלת). פרץ של אלה בחלון קצר הוא credential stuffing. נתב לערוץ ה-on-call שלך.

צעדים הבאים

הרץ סריקת FixVibe מול URL הייצור שלך — בדיקת baas.clerk-auth0 מסמנת סודות לקוח של Auth0 מצורפים ב-JavaScript ומחלקות חשיפה אחרות של ספק זהויות. למקבילה ב-Clerk, ראה רשימת בדיקה לאבטחת Clerk. לתצוגה מקיפה על פני ספקי BaaS, קרא סורק תצורות שגויות של BaaS.