// docs / baas security / clerk hardening

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

Clerk-ը կառավարում է քո հավելվածի auth-ը, սեսիաները և կազմակերպությունները — ինչը նշանակում է, որ սխալ կարգավորված Clerk ինտեգրացիան auth-ի շրջանցում է, սեսիա-ֆիքսացիայի վեկտոր կամ org-արտահոսքի ուղի։ Այս ստուգաթերթը 20-կետանի աուդիտ է բանալիների, սեսիայի կարգավորման, webhook-ների, կազմակերպությունների, JWT template-ների և ընթացիկ մոնիտորինգի վրա։ AI-ի կոդավորման գործիքները լարում են Clerk-ը արագ՝ ողջամիտ լռելյայններով. այս ցուցակը գտնում է այն կետերը, որ նրանք թողնում են սեղանին։

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

Միջավայրի բանալիներ և origin allowlist

Clerk-ը տալիս է երկու տարբեր բանալի յուրաքանչյուր նախագծի համար։ Դրանք խառնելը կամ արտահոսելը առաջին ձախողման ռեժիմն է։

Օգտագործիր publishable բանալին (pk_live_* production-ում, pk_test_* dev-ում) զննարկիչում. օգտագործիր secret բանալին (sk_live_* / sk_test_*) միայն սերվերի վրա։ Publishable բանալին անվտանգ է NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY-ում. secret բանալին երբեք չպետք է կրի հանրային env նախածանց և երբեք չպետք է հայտնվի client բաղադրիչում։
Ստուգիր, որ production հավելվածն օգտագործում է pk_live_*, ոչ pk_test_*։ Test instance-ները թույլատրում են չվավերացված էլ. փոստի հասցեներ և անջատված MFA — production-ին test mode առաքելը auth-ի շրջանցում է։
Կարգավորիր թույլատրված origin-ները Clerk Dashboard-ում։ Settings → Domains → Allowed origins պետք է թվարկի քո production տիրույթը ճշգրիտ։ Դատարկ կամ wildcard origin ցուցակները թույլ են տալիս հարձակվողներին ստեղծել կեղծ Clerk ֆրոնտէնդեր, որ խոսում են քո backend-ի հետ։
Պտտիր secret բանալին ցանկացած աշխատանքից ազատման կամ կասկածելի արտահոսքի դեպքում։ Dashboard → API Keys → Reset։ Հին բանալին անվավեր է. կրկին deploy արա սերվերային կոդը նոր արժեքով՝ պտտելուց առաջ։

Սեսիայի կարգավորում

Սեսիայի ժամկետի սպառումը և անգործության timeout-ները տարբերությունն են գողացված սեսիայի 10-րոպեանոց միջադեպ լինելու և 30-օրյա միջադեպ լինելու միջև։

Սահմանիր սեսիայի անգործության timeout 30 րոպե կամ պակաս SaaS հավելվածների համար, որ զգայուն տվյալներ են մշակում։ Dashboard → Sessions → Inactivity timeout։ Բանկ-մակարդակի հավելվածները պետք է օգտագործեն 5-10 րոպե. ստանդարտ SaaS՝ 30-60 րոպե. սպառողական հավելվածներ՝ 1-7 օր։ Լռելյայնը 7 օր է։
Միացրու սեսիայի չեղարկումը գաղտնաբառի փոփոխման, էլ. փոստի փոփոխման և MFA գրանցման դեպքում։ Dashboard → Sessions → Revoke on։ Սրանք օգտատիրոջ նախաձեռնած անվտանգության իրադարձություններ են. այլ սարքերի վրա առկա սեսիաները պետք է սպանվեն։
Ստուգիր սեսիաները սերվերային կողմից յուրաքանչյուր պաշտպանված route-ում, ոչ միայն մուտքի ժամանակ։ Next.js-ում․ const { userId } = await auth(); server բաղադրիչում / API route-ում կարդում է JWT-ն cookie-ից և վավերացնում։ Երբեք մի վստահիր միայն-cookie ստուգմանը։
Սահմանիր SameSite=Lax (լռելյայն) կամ Strict սեսիայի cookie-ի վրա։ Ստուգիր DevTools → Application → Cookies-ում։ SameSite=None-ը CSRF վեկտոր է — երբեք մի օգտագործիր, քանի դեռ բացահայտ չես կարգավորել cross-domain auth setup։

Webhook-ի վավերացում

Clerk webhook-ները կրակում են օգտատիրոջ կյանքի ցիկլի իրադարձություններից (created, updated, deleted, session.ended)։ Դրանք քո տվյալների բազայի համաժամացման մեխանիզմն են — և կեղծված webhook-ը տվյալների բազայի-գրառման պրիմիտիվ է։

Վավերացրու Svix ստորագրությունը յուրաքանչյուր webhook-ի վրա։ Clerk webhook-ները ստորագրված են Svix-ի կողմից։ Օգտագործիր new Webhook(secret).verify(body, headers)։ Մերժիր 401-ով, եթե վավերացումը ձախողվում է։
Պահպանիր webhook secret-ը միջավայրի փոփոխականում, երբեք կոդում։ Secret-ը պտտվում է յուրաքանչյուր Dashboard վերագեներացման ժամանակ — քո deploy-ը պետք է կարդա այն env-ից, ոչ թե հաստատունից։
Idempotency յուրաքանչյուր handler-ի վրա։ Webhook delivery-ները կարող են կրկնվել։ Օգտագործիր svix-id header-ը որպես primary key webhook_events table-ում deduplicate-ի համար։ Փաթաթիր վիճակի փոփոխությունը և idempotency insert-ը նույն տրանզակցիայում։
user.deleted-ի դեպքում, ֆիզիկապես ջնջիր կամ անանուն դարձրու PII-ն 24 ժամվա ընթացքում։ GDPR / CCPA-ն դա պահանջում են։ Աուդիտ արա ջնջման ուղին․ որ table-ները պարունակում են այս օգտատիրոջ տվյալները։ Օգտագործիր FK ON DELETE CASCADE, որտեղ կարող ես։

Կազմակերպություններ և թույլտվություններ

Եթե օգտագործում ես Clerk Organizations, org սահմանը քո վարձակալների մեկուսացումն է։ Յուրաքանչյուր սերվերային հարցում պետք է զտել ըստ դրա։

Յուրաքանչյուր API route-ում կարդա և՛ userId-ն, և՛ orgId-ն auth()-ից և զտիր տվյալների բազայի հարցումները երկուսով։ WHERE org_id = $orgId AND user_id = $userId։ Երբեք մի վստահիր org_id-ին հարցման մարմնից։
<strong>Use Clerk role checks for privileged operations, not boolean checks against the user object.</strong> <code>has({ role: 'org:admin' })</code> reads the role from the verified JWT. A user can spoof a boolean on a stale client object; they cannot spoof a JWT claim.
Թեստավորիր org-ների միջև մեկուսացումը երկու իրական org հաշիվներով։ Ստեղծիր Org A, լրացրու տվյալները, մուտք գործիր Org B մեկ այլ զննարկչում, փորձիր կարդալ Org A-ի տվյալները API-ի միջոցով։ Պատասխանը պետք է լինի 403 կամ 404։

JWT template-ներ և արտաքին ինտեգրացիաներ

JWT template-ները Clerk-ի ինքնությունը մղում են Supabase-ին, Firebase-ին և այլ ներքևի ծառայություններին։ Սխալ կարգավորված template-ները չափից շատ claim են կիսում կամ բացահայտում տվյալներ, որ դու չէիր նկատի ունեցել։

Յուրաքանչյուր JWT template-ի համար թվարկիր յուրաքանչյուր claim և հաստատիր, որ այն անհրաժեշտ է։ Dashboard → JWT Templates։ Template, որ ուղարկում է email և phone Supabase-ին, բացահայտում է PII-ն ցանկացած մեկին, ով JWT-ն կարդում է զննարկիչում։
Սահմանիր կարճ ժամկետ JWT template-ների վրա, որ օգտագործվում են client-side ներքևի կանչերի համար։ 60 վայրկյանը ստանդարտ է ներքևի API հարցումների համար։ Երկար ապրող JWT-ները գողանում են և կրկնագործարկում։
Ստուգիր audience (aud) claim-ն ստացող կողմում։ Supabase, Firebase և այլք պետք է ստուգեն, որ aud-ը համապատասխանում է ակնկալվող ծառայության նույնացուցիչին։ Առանց դրա, ծառայություն A-ի համար տրված JWT-ն կարող է վավերանալ ծառայություն B-ին։

Գործառնական մոնիտորինգ

Auth-ը ամենաբարձր ազդանշանի log աղբյուրն է, որ ունես։ Հետևիր դրան։

Ազդանշան տուր ձախողված-մուտքի աճերի մասին IP-ի / հաշվի համար։ Նորմալ ձախողման 50× արագությունը credential-stuffing հարձակում է։ Clerk-ն այս իրադարձությունները ուղարկում է webhook-ներին. ուղղորդիր դրանք քո SIEM-ին։
Եռամսյակային վերանայում սեսիայի և instance-ի կարգավորումների շեղման։ Լռելյայնները փոխվում են, քանի որ Clerk-ը թարմացվում է. «հին կարգավորումները» լուռ դառնում են սխալ ժամանակի ընթացքում։ Համեմատիր Dashboard JSON export-ը քո վերջին-հայտնի-լավի օրինակի հետ։

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

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