// docs / baas security / clerk hardening

Lista kontrolna bezpieczeństwa Clerk: 20 elementów

Clerk obsługuje uwierzytelnianie, sesje i organizacje dla Twojej aplikacji — co oznacza, że błędnie skonfigurowana integracja Clerk to obejście uwierzytelniania, wektor utrwalenia sesji lub ścieżka wycieku organizacji. Ta lista kontrolna to 20-elementowy audyt obejmujący klucze, konfigurację sesji, webhooki, organizacje, szablony JWT i bieżące monitorowanie. Narzędzia kodowania AI szybko podłączają Clerk z rozsądnymi wartościami domyślnymi; ta lista łapie elementy, które pozostawiają na stole.

Dla tła, dlaczego błędne konfiguracje warstwy uwierzytelniania są słabym punktem narzędzi AI, zobacz Dlaczego narzędzia kodowania AI pozostawiają luki w bezpieczeństwie. Dla równoległej listy kontrolnej w Auth0 zobacz Lista kontrolna bezpieczeństwa Auth0.

Klucze środowiska i lista dozwolonych pochodzeń

Clerk wystawia dwa różne klucze na projekt. Ich mieszanie lub wyciekanie to pierwszy tryb awarii.

Użyj klucza publicznego (pk_live_* w produkcji, pk_test_* w deweloperskim) w przeglądarce; użyj klucza sekretnego (sk_live_* / sk_test_*) tylko na serwerze. Klucz publiczny jest bezpieczny w NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; klucz sekretny nigdy nie może mieć publicznego prefiksu env i nigdy nie może pojawiać się w komponencie klienta.
Zweryfikuj, że aplikacja produkcyjna używa pk_live_*, a nie pk_test_*. Instancje testowe pozwalają na niezweryfikowane adresy e-mail i wyłączone MFA — wysyłanie trybu testowego do produkcji to obejście uwierzytelniania.
Skonfiguruj dozwolone pochodzenia w panelu Clerk. Settings → Domains → Allowed origins muszą dokładnie wymieniać Twoją produkcyjną domenę. Puste lub wieloznaczne listy pochodzeń pozwalają atakującym tworzyć fałszywe interfejsy Clerk, które komunikują się z Twoim backendem.
Obróć klucz sekretny przy każdym odejściu lub podejrzeniu wycieku. Panel → API Keys → Reset. Stary klucz jest unieważniony; ponownie wdróż kod po stronie serwera z nową wartością przed rotacją.

Konfiguracja sesji

Wygaśnięcie sesji i limity czasu bezczynności to różnica między tym, czy skradziona sesja jest incydentem 10-minutowym czy 30-dniowym.

Ustaw limit czasu bezczynności sesji na 30 minut lub mniej dla aplikacji SaaS obsługujących wrażliwe dane. Panel → Sessions → Inactivity timeout. Aplikacje klasy bankowej powinny używać 5-10 minut; standardowy SaaS 30-60 minut; aplikacje konsumenckie 1-7 dni. Domyślnie 7 dni.
Włącz unieważnienie sesji przy zmianie hasła, zmianie e-maila i rejestracji MFA. Panel → Sessions → Revoke on. To są zdarzenia bezpieczeństwa zainicjowane przez użytkownika; istniejące sesje na innych urządzeniach powinny być zabite.
Weryfikuj sesje po stronie serwera na każdej chronionej trasie, nie tylko przy logowaniu. W Next.js: const { userId } = await auth(); w komponencie serwera / trasie API odczytuje JWT z ciasteczka i waliduje go. Nigdy nie ufaj samej kontroli ciasteczek.
Ustaw SameSite=Lax (domyślnie) lub Strict na ciasteczku sesji. Zweryfikuj w DevTools → Application → Cookies. SameSite=None to wektor CSRF — nigdy nie używaj, chyba że jawnie skonfigurowałeś konfigurację uwierzytelniania międzydomenowego.

Weryfikacja webhooka

Webhooki Clerk uruchamiają się przy zdarzeniach cyklu życia użytkownika (created, updated, deleted, session.ended). Są mechanizmem synchronizacji dla Twojej bazy danych — a sfałszowany webhook to prymityw zapisu do bazy danych.

Weryfikuj podpis Svix na każdym webhooku. Webhooki Clerk są podpisane przez Svix. Użyj new Webhook(secret).verify(body, headers). Odrzucaj z 401, jeśli weryfikacja się nie powiedzie.
Przechowuj sekret webhooka w zmiennej środowiskowej, nigdy w kodzie. Sekret rotuje przy każdej regeneracji w panelu — Twoje wdrożenie musi go odczytywać z env, a nie ze stałej.
Idempotencja w każdym handlerze. Dostawy webhooków mogą się powtarzać. Użyj nagłówka svix-id jako klucza głównego w tabeli webhook_events, aby usuwać duplikaty. Owiń zmianę stanu i wstawienie idempotencji w tej samej transakcji.
Przy user.deleted twardo usuń lub anonimizuj PII w ciągu 24 godzin. GDPR / CCPA tego wymagają. Sprawdź ścieżkę usuwania: które tabele przechowują dane tego użytkownika? Użyj FK ON DELETE CASCADE tam, gdzie możesz.

Organizacje i uprawnienia

Jeśli używasz Clerk Organizations, granica organizacji to Twoja izolacja najemcy. Każde zapytanie po stronie serwera musi filtrować według niej.

Na każdej trasie API odczytuj zarówno userId, jak i orgId z auth() i filtruj zapytania bazy danych według obu. WHERE org_id = $orgId AND user_id = $userId. Nigdy nie ufaj org_id z ciała żądania.
<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.
Przetestuj izolację międzyorganizacyjną z dwoma prawdziwymi kontami org. Utwórz Org A, wypełnij dane, zaloguj się do Org B w innej przeglądarce, spróbuj odczytać dane Org A przez API. Odpowiedź musi być 403 lub 404.

Szablony JWT i integracje zewnętrzne

Szablony JWT przesyłają tożsamość Clerk do Supabase, Firebase i innych usług w dół strumienia. Błędnie skonfigurowane szablony nadmiernie dzielą się roszczeniami lub ujawniają dane, których nie chciałeś.

Dla każdego szablonu JWT wymień każde roszczenie i potwierdź, że jest konieczne. Panel → JWT Templates. Szablon, który wysyła email i phone do Supabase, ujawnia PII każdemu, kto czyta JWT w przeglądarce.
Ustaw krótkie wygaśnięcie na szablonach JWT używanych do wywołań w dół strumienia po stronie klienta. 60 sekund dla żądań API w dół strumienia to standard. Długowieczne JWT są kradzione i odtwarzane.
Zweryfikuj roszczenie audience (aud) po stronie odbiorcy. Supabase, Firebase itp. powinny sprawdzać, że aud pasuje do oczekiwanego identyfikatora usługi. Bez tego JWT wystawiony dla usługi A może uwierzytelniać się w usłudze B.

Monitorowanie operacyjne

Uwierzytelnianie to najwyższe źródło logów sygnałowych, jakie masz. Obserwuj je.

Alarmuj przy szczytach nieudanych logowań na IP / konto. 50× normalnej szybkości niepowodzeń to atak credential stuffing. Clerk emituje te zdarzenia do webhooków; kieruj je do swojego SIEM.
Kwartalny przegląd dryfu ustawień sesji i instancji. Wartości domyślne zmieniają się w miarę aktualizacji Clerk; „stare konfiguracje" cicho stają się błędne z czasem. Porównaj eksport JSON panelu z ostatnio znaną dobrą kopią.

Następne kroki

Uruchom skanowanie FixVibe wobec swojego produkcyjnego URL — kontrola baas.clerk-auth0 flaguje klucze publiczne Clerk, klucze testowe w produkcji i pakietowane klucze sekretne. Dla równoważnej listy kontrolnej w Auth0 zobacz Lista kontrolna bezpieczeństwa Auth0. Dla widoku parasolowego obejmującego dostawców BaaS przeczytaj Skaner błędnych konfiguracji BaaS.