// docs / baas security / clerk hardening

Clerk-ის უსაფრთხოების სია: 20 პუნქტი

Clerk მართავს auth-ს, სესიებს და ორგანიზაციებს თქვენი აპისთვის — რაც ნიშნავს, რომ არასწორად კონფიგურირებული Clerk-ის ინტეგრაცია არის auth-ის გვერდს ავლა, სესიის-დაფიქსაციის ვექტორი ან ორგ-ჟონვის გზა. ეს სია არის 20-პუნქტიანი აუდიტი გასაღებებზე, სესიის კონფიგურაციაზე, webhook-ებზე, ორგანიზაციებზე, JWT-შაბლონებზე და მიმდინარე მონიტორინგზე. AI-კოდირების ხელსაწყოები სწრაფად აკავშირებენ Clerk-ს გონივრული ნაგულისხმევებით; ეს სია იჭერს იმ პუნქტებს, რომელსაც ისინი ტოვებენ.

ფონური ინფორმაციისთვის, რატომ არის auth-ფენის არასწორი კონფიგურაციები AI-ხელსაწყოს სუსტი წერტილი, ნახეთ რატომ ტოვებენ AI-კოდირების ხელსაწყოები უსაფრთხოების ხარვეზებს. პარალელური სიისთვის Auth0-ზე, ნახეთ Auth0-ის უსაფრთხოების სია.

გარემოს გასაღებები და origin-დაშვების სია

Clerk გასცემს ორ განსხვავებულ გასაღებს პროექტზე. მათი შერევა ან ჟონვა არის პირველი შეცდომის რეჟიმი.

გამოიყენეთ გამოსაქვეყნებელი გასაღები (pk_live_* პროდუქციაში, pk_test_* dev-ში) ბრაუზერში; გამოიყენეთ secret-გასაღები (sk_live_* / sk_test_*) მხოლოდ სერვერზე. გამოსაქვეყნებელი გასაღები უსაფრთხოა NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY-ში; secret-გასაღებს არასოდეს არ უნდა ჰქონდეს საჯარო env-პრეფიქსი და არასოდეს უნდა ჩნდებოდეს კლიენტის კომპონენტში.
დაამოწმეთ, რომ პროდუქციის აპი იყენებს pk_live_*-ს, არა pk_test_*-ს. ტესტ-ინსტანციები დაუშვებენ არავერიფიცირებულ ელფოსტის მისამართებს და გათიშულ MFA-ს — ტესტ-რეჟიმის გადატანა პროდუქციაში არის auth-ის გვერდს ავლა.
კონფიგურირეთ დაშვებული origin-ები Clerk Dashboard-ში. Settings → Domains → Allowed origins უნდა ჩამოთვალოს თქვენი პროდუქციის დომენი ზუსტად. ცარიელი ან wildcard origin-სიები აძლევენ თავდამსხმელებს, შექმნან მზაკვრული Clerk-frontend-ები, რომლებიც თქვენი backend-ს ესაუბრებიან.
შეცვალეთ secret-გასაღები ნებისმიერი წასვლისას ან ეჭვმიტანილი ჟონვისას. Dashboard → API Keys → Reset. ძველი გასაღები აუქმდება; თავიდან გადააგზავნეთ სერვერის მხარის კოდი ახალი მნიშვნელობით, სანამ შეცვლა მოხდება.

სესიის კონფიგურაცია

სესიის ვადის გასვლა და უმოქმედობის ვადები არის განსხვავება მოპარული სესიის 10-წუთიან ინციდენტად ყოფნასა და 30-დღიანად ყოფნას შორის.

დააწესეთ სესიის უმოქმედობის ვადა 30 წუთზე ან ნაკლებზე SaaS-აპებისთვის, რომლებიც სენსიტიურ მონაცემებს ამუშავებენ. Dashboard → Sessions → Inactivity timeout. საბანკო-დონის აპები უნდა იყენებდნენ 5-10 წუთს; სტანდარტული SaaS 30-60 წუთს; სამომხმარებლო აპები 1-7 დღეს. ნაგულისხმევი არის 7 დღე.
ჩართეთ სესიის გაუქმება პაროლის ცვლისას, ელფოსტის ცვლისას და MFA-ში ჩაწერისას. Dashboard → Sessions → Revoke on. ეს არის მომხმარებლის-ინიცირებული უსაფრთხოების მოვლენები; არსებული სესიები სხვა მოწყობილობებზე უნდა მოკლდეს.
დაამოწმეთ სესიები სერვერის მხარეს ყოველ დაცულ მარშრუტზე, არა მხოლოდ შესვლისას. Next.js-ში: const { userId } = await auth(); სერვერის კომპონენტში / API-მარშრუტში კითხულობს JWT-ს cookie-დან და დაამოწმებს. არასოდეს ენდოთ მხოლოდ-cookie შემოწმებას.
დააწესეთ SameSite=Lax (ნაგულისხმევი) ან Strict სესიის cookie-ზე. დაამოწმეთ DevTools → Application → Cookies-ში. SameSite=None არის CSRF-ვექტორი — არასოდეს გამოიყენოთ ის, თუ არ კონფიგურირებთ ცხადად ჯვარედინი-დომენის auth-დაყენებას.

Webhook-ის ვერიფიკაცია

Clerk-ის webhook-ები აისროლება მომხმარებლის სასიცოცხლო ციკლის მოვლენებზე (created, updated, deleted, session.ended). ისინი არიან თქვენი მონაცემთა ბაზის სინქრონიზაციის მექანიზმი — და გაყალბებული webhook არის მონაცემთა ბაზის-ჩაწერის პრიმიტივი.

დაამოწმეთ Svix-ხელმოწერა ყოველ webhook-ზე. Clerk-ის webhook-ები ხელმოწერილია Svix-ით. გამოიყენეთ new Webhook(secret).verify(body, headers). უარყავით 401-ით, თუ ვერიფიკაცია ვერ მოხდა.
შეინახეთ webhook-ის საიდუმლო გარემოს ცვლადში, არასოდეს კოდში. საიდუმლო იცვლება ყოველი Dashboard-რეგენერაციისას — თქვენი დეპლოი უნდა კითხულობდეს მას env-დან, არა კონსტანტიდან.
Idempotency-ი ყოველ ჰენდლერზე. Webhook-მიწოდებები შეიძლება გამეორდეს. გამოიყენეთ svix-id header როგორც პირველადი გასაღები webhook_events ცხრილში დედუპლიკაციისთვის. გახვიეთ მდგომარეობის ცვლა და idempotency-ჩასმა იმავე ტრანზაქციაში.
user.deleted-ზე ხელით წაშალეთ ან გააანონიმეთ PII 24 საათში. GDPR / CCPA მოითხოვს. ჩაატარეთ წაშლის გზის აუდიტი: რომელი ცხრილები ფლობენ ამ მომხმარებლის მონაცემებს? გამოიყენეთ FK ON DELETE CASCADE, სადაც შეგიძლიათ.

ორგანიზაციები და ნებართვები

თუ იყენებთ Clerk-ის ორგანიზაციებს, ორგ-საზღვარი არის თქვენი არენდატორის იზოლაცია. ყოველი სერვერის მხარის შეკითხვა უნდა ფილტრავდეს მის მიხედვით.

ყოველ API-მარშრუტზე წაიკითხეთ როგორც 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.
დაატესტეთ ჯვარედინი-ორგ-ის იზოლაცია ორი რეალური ორგ-ანგარიშით. შექმენით ორგ A, შეავსეთ მონაცემები, შედით ორგ B-ში სხვა ბრაუზერში, სცადეთ წაიკითხოთ ორგ A-ის მონაცემები API-ით. პასუხი უნდა იყოს 403 ან 404.

JWT-შაბლონები და გარე ინტეგრაციები

JWT-შაბლონები Clerk-ის ვინაობას აშოშინებენ Supabase-ში, Firebase-სა და სხვა ქვედინ სერვისებში. არასწორად კონფიგურირებული შაბლონები ზედმეტად აზიარებენ claim-ებს ან ავლენენ მონაცემებს, რომელთა გამოვლენა არ გსურდათ.

ყოველი JWT-შაბლონისთვის ჩამოთვალეთ ყოველი claim და დაამოწმეთ, რომ ის აუცილებელია. Dashboard → JWT Templates. შაბლონი, რომელიც აგზავნის email-სა და phone-ს Supabase-ში, ავლენს PII-ს ნებისმიერ ადამიანს, ვინც ბრაუზერში JWT-ს კითხულობს.
დააწესეთ მოკლე ვადის გასვლა JWT-შაბლონებზე, რომლებიც გამოიყენება კლიენტის მხარის ქვედინი გამოძახებებისთვის. 60 წამი ქვედინი API-მოთხოვნებისთვის არის სტანდარტი. უფრო ხანგრძლივი JWT-ები იპარება და გადათამაშდება.
დაამოწმეთ audience (aud) claim მიმღების მხარეს. Supabase, Firebase და ა.შ. უნდა შეამოწმონ, რომ aud ემთხვევა მოსალოდნელ სერვისის იდენტიფიკატორს. ამის გარეშე, JWT, რომელიც გაცემული იყო სერვის A-სთვის, შეუძლია სერვის B-ში ავთენტიფიკაცია.

ოპერაციული მონიტორინგი

Auth არის ყველაზე მაღალი-სიგნალის ლოგის წყარო, რომელიც გაქვთ. დაუდევრად ნუ მოეპყრობით.

გააფრთხილეთ ვერ-შესვლის ბუნებზე IP-ზე / ანგარიშზე. ნორმალური წარუმატებლობის სიხშირის 50× არის credential-stuffing შეტევა. Clerk აისროლებს ამ მოვლენებს webhook-ებზე; გადაუგზავნეთ ისინი თქვენს SIEM-ს.
კვარტალური მიმოხილვა სესიის და ინსტანციის პარამეტრების დრიფტისთვის. ნაგულისხმევები იცვლება Clerk-ის განახლებებთან ერთად; „ძველი კონფიგურაციები" ჩუმად არასწორი ხდება დროთა განმავლობაში. შეადარეთ Dashboard JSON-ექსპორტი თქვენი ბოლო-ცნობილი-კარგი ასლის წინააღმდეგ.

შემდეგი ნაბიჯები

გაუშვით FixVibe-სკანი თქვენი პროდუქციის URL-ის წინააღმდეგ — baas.clerk-auth0 შემოწმება მონიშნავს Clerk-ის გამოსაქვეყნებელ გასაღებებს, ტესტ-გასაღებებს პროდუქციაში და ბანდლირებულ secret-გასაღებებს. Auth0-ის ეკვივალენტური სიისთვის, ნახეთ Auth0-ის უსაფრთხოების სია. BaaS-პროვაიდერებზე ერთიანი ხედვისთვის, წაიკითხეთ BaaS-ის არასწორი კონფიგურაციის სკანერი.