// docs / baas security / auth0 hardening

Auth0-ի անվտանգության ստուգաթերթ․ 22 կետ

Auth0-ը ինքնության-որպես-ծառայություն հարթակ է հսկայական մակերեսով — հավելվածներ, API-ներ (resource server-ներ), tenant-ներ, action-ներ, rule-ներ (ժառանգային), connection-ներ և grant-ներ։ Որևէ մեկի սխալ կարգավորումը auth-ի շրջանցում է։ Այս ստուգաթերթը 22-կետանի աուդիտ է հավելվածների, callback / logout allowlist-ների, token-ների և refresh պտտման, custom action-ների, RBAC-ի, անոմալիաների հայտնաբերման և ընթացիկ մոնիտորինգի վրա։ Յուրաքանչյուր կետ ստուգելի է Auth0 Dashboard-ում 10 րոպեից պակաս ժամանակում։

Clerk-ի վրա համարժեք ստուգաթերթի համար տես Clerk-ի անվտանգության ստուգաթերթ։ Ինքնության-շերտի սխալ կարգավորումները AI-գործիքի կույր կետեր լինելու ֆոնի համար տես Ինչու AI-ի կոդավորման գործիքները թողնում են անվտանգության բացեր։

Հավելվածի տեսակ և grant տեսակներ

Հավելվածի տեսակը և միացված grant տեսակները Auth0-ում ամենաբարձր-ազդեցության կարգավորումներն են։ Դրանք սխալ ստանալը բացում է հարձակման դասեր, որոնք ոչ մի ֆրոնտէնդ կոդ չի փակի։

Օգտագործիր Application Type = Single Page Application միայն-զննարկիչ հավելվածների համար և Regular Web Application server-rendered հավելվածների համար։ Սխալ տեսակը թույլ է տալիս սխալ grant տեսակները — օրինակ, Regular Web App, որ ունի SPA grant-ը, միացնում է PKCE-ից զուրկ Implicit flow-ը, որը արտահոսում է token-ները URL fragment-ների միջոցով։
Անջատիր Implicit grant տեսակը յուրաքանչյուր հավելվածի վրա։ Dashboard → Application → Advanced Settings → Grant Types → ապանշիր Implicit-ը։ Implicit flow-ը վերադարձնում է token-ները URL fragment-ներում, որտեղ դրանք գրառվում են զննարկչի պատմության մեջ և analytics-ում։ Օգտագործիր Authorization Code PKCE-ով։
Անջատիր Password grant-ը, քանի դեռ չունես փաստագրված կարիք։ Resource Owner Password Credentials (ROPC) grant-ը պահանջում է, որ դու ինքդ կառավարես օգտատերերի գաղտնաբառերը — հաղթահարելով Auth0-ի համար վճարածդ բանի մեծ մասը։ Անջատիր այն, քանի դեռ չես ինտեգրում ժառանգային համակարգ։
Միացրու Authorization Code PKCE-ով յուրաքանչյուր հանրային client-ի վրա։ Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = enabled։ PKCE-ն պահանջվում է բջջային հավելվածների և SPA-ների համար՝ կոդի կտրման կանխման համար։

Callback և logout URL allowlist-ներ

Բաց redirect-ները OAuth callback ուղու վրա token-գողության պրիմիտիվ են։ Auth0-ի allowlist-ը քո միակ պաշտպանությունն է։

Սահմանիր Allowed Callback URLs-ը քո ճշգրիտ production callback ուղով — առանց wildcard-ների։ https://yourapp.com/callback, ոչ https://yourapp.com/*։ Wildcard callback-ները թույլ են տալիս հարձակվողներին վերաուղորդել token-ները քո տիրույթի կամայական ենթաուղիների։
Սահմանիր Allowed Logout URLs-ը վերջավոր ցուցակի։ Նույն կանոնը․ միայն բացահայտ URL-ներ։ Բաց logout redirect-ը թույլ է տալիս հարձակվողներին ստեղծել phishing էջեր, որ նման են քո post-logout վիճակին։
Սահմանիր Allowed Web Origins-ը միայն քո production origin-ի։ Օգտագործվում է լուռ վավերացման համար (token-ի թարմացում թաքնված iframe-ի միջոցով)։ Wildcard origin-ը թույլ է տալիս հարձակվող էջերին լուռ auth իրականացնել քո tenant-ի դեմ։
Սահմանիր Allowed CORS origin-ները API endpoint-ների համար, ոչ թե հավելվածի։ Tenant Settings → Advanced → Allowed CORS origins։ Լռելյայնը դատարկ է (սահմանափակված). ավելացրու միայն բացահայտ origin-ներ, որոնք վերահսկում ես։

Token-ներ և refresh պտտում

Token-ի կյանքի տևողությունը, refresh պտտումը և ստորագրման ալգորիթմը որոշում են ցանկացած token-ի արտահոսքի պայթյունի շառավիղը։

Միացրու Refresh Token Rotation-ը։ Application → Refresh Token Settings → Rotation։ Յուրաքանչյուր refresh թողարկում է նոր refresh token և անվավեր է անում հինը։ Համատեղ բացարձակ ժամկետի սպառման հետ, սա սահմանափակում է token-ի գողությունը։
Սահմանիր Refresh Token Reuse Interval-ը 0 (կամ որքան ցածր, որքան քո replay հանդուրժողականությունը թույլ է տալիս)։ Reuse interval-ը թույլ է տալիս token-ին օգտագործվել երկու անգամ նույն պատուհանում — անջատիր այն, քանի դեռ կոնկրետ պատճառ չունես պահելու։
Սահմանիր Absolute Refresh Token Expiry-ն 14-30 օր, ոչ թե անվերջություն։ Application → Refresh Token Expiration → Absolute Expiration։ Auth0-ն լռելյայն օգտագործում է միայն-Inactivity, ինչը նշանակում է, որ պարապ սեսիան կարող է գոյատևել տարիներով։
Սահմանիր JWT Signature Algorithm-ը RS256։ Application → Advanced → OAuth → JsonWebToken Signature Algorithm։ RS256-ը օգտագործում է ասիմետրիկ ստորագրում, որպեսզի client-ը չկարողանա կեղծել token-ները։ Երբեք մի օգտագործիր HS256-ը client-ի համար տեսանելի հավելվածների համար։
Ստուգիր aud և iss claim-ները յուրաքանչյուր JWT-ի վրա, որ ստանում է քո API-ն։ Օգտագործիր Auth0-ի պաշտոնական SDK-ն սերվերային կողմից — այն ինքնաբերաբար վավերացնում է դրանք։ Ձեռքով JWT parsing-ը սովորաբար բաց է թողնում audience վավերացումը, ինչը auth-ի շրջանցում է։

Action-ներ և custom կոդ

Auth0 Action-ները (և ժառանգային Rule-ները) աշխատում են սերվերային կողմից մուտքի և կյանքի ցիկլի այլ իրադարձությունների ժամանակ։ Նրանք մուտք ունեն ողջ հարցման համատեքստին։ Անապահով կոդը այստեղ tenant-մակարդակի խոցելիություն է։

Երբեք մի գրառիր event.user-ը կամ event.transaction-ը որպես ողջ օբյեկտ։ Դրանք պարունակում են էլ. փոստի հասցեներ, IP հասցեներ և այլ PII։ Օգտագործիր միայն դաշտ-մակարդակի գրառում և միայն այն, ինչ քեզ պետք է։
Օգտագործիր secret store ցանկացած API բանալու կամ webhook URL-ի համար։ Actions → Edit → Secrets։ Երբեք մի inline արա API բանալին որպես string literal action կոդում — կոդը տեսանելի է ցանկացածին, ով tenant-ում Action editor-ի մուտք ունի։
Վավերացրու input-ները, քանի դեռ չես պահպանել դրանք որպես user_metadata կամ app_metadata։ Ինքնասպասարկման action, որ գրում է event.body.name-ը user.user_metadata.display_name-ին, պահված-XSS վեկտոր է, եթե քո ֆրոնտէնդն այդ դաշտը ռենդր է անում առանց escape-ի։

RBAC և resource server-ներ

Եթե օգտագործում ես Auth0 RBAC-ը, role-ի-թույլտվության նկարագրումը քո վավերացման շերտն է։ Սխալ ստանաս՝ ցանկացած վավերացված օգտատեր կարող է հարվածել admin endpoint-ներին։

Հատկորոշիր Resource Server-ները (API-ները) բացահայտ Auth0 Dashboard-ում, ոչ թե թռչուն-ընկած։ Յուրաքանչյուր API-ն ունի նույնացուցիչ (audience), scope-եր և ստորագրման կարգավորումներ։ Առանց գրանցված API-ի, բոլոր token-ները տրվում են ենթադրյալ «Auth0 Management API»-ի համար — սխալ audience։
Կարգավորիր թույլտվությունները ըստ API-ի և քո կոդում պահանջիր դրանք scope claim-ով։ Մի ստուգիր role-ի անդամակցությունը քո հավելվածի լոգիկայում. ստուգիր scope-երը access token-ում։ Scope-երը OAuth-ի-բնիկ վավերացման մեխանիզմն են։
Թեստավորիր, որ վավերացված օգտատերը՝ առանց պահանջվող role-ի / scope-ի, չի կարող հարվածել արտոնյալ endpoint-ներին։ Մուտք գործիր որպես սովորական օգտատեր, փորձիր կանչել POST /api/admin/users/delete։ Պատասխանը պետք է լինի 403։

Անոմալիաների հայտնաբերում և tenant log-եր

Auth0-ն թողարկում է բարձր-ազդանշանի իրադարձություններ։ Կարգավորիր դրանք քո թիմին ազդանշան տալու համար, ոչ թե պարզապես log buffer-ում նստել։

Միացրու Attack Protection-ը․ Bot Detection, Brute Force, Suspicious IP Throttling։ Dashboard → Security → Attack Protection։ Յուրաքանչյուրն անջատված է լռելյայն անվճար փաթեթներում. միացրու բոլորը production-ի համար։
Հոսքավորիր tenant log-երը SIEM-ին կամ քո հավելվածի log-երին։ Dashboard → Monitoring → Streams։ Auth0-ն պահում է log-երը 30 օր փաթեթների մեծ մասում. երկարատև պահպանումը պահանջում է հոսք քո սեփական համակարգ։
Ազդանշան տուր fcoa (failed cross-origin auth) և fp (failed login) աճերի մասին։ Կարճ պատուհանում սրանց աճը credential stuffing է։ Ուղղորդիր քո on-call ալիքին։

Հաջորդ քայլեր

Գործարկիր FixVibe սկան քո production URL-ի դեմ — baas.clerk-auth0 ստուգումը նշում է JavaScript-ում bundle-ված Auth0 client secret-ները և ինքնության-մատակարարի այլ բացահայտման դասերը։ Clerk-ի վրա համարժեքի համար տես Clerk-ի անվտանգության ստուգաթերթ։ Բոլոր BaaS մատակարարների միասնական տեսքի համար կարդա BaaS սխալ կարգավորման սկաներ։