// docs / baas security / clerk hardening

Kontrolní seznam zabezpečení Clerk: 20 položek

Clerk obsluhuje autentizaci, relace a organizace pro vaši aplikaci — což znamená, že chybně nakonfigurovaná integrace Clerk je obejití autentizace, vektor session-fixation nebo cesta k úniku org. Tento kontrolní seznam je 20bodový audit napříč klíči, konfigurací relací, webhooky, organizacemi, JWT šablonami a průběžným monitoringem. AI nástroje pro kódování rychle zapojí Clerk s rozumnými výchozími hodnotami; tento seznam zachycuje položky, které vynechávají.

Pro pozadí toho, proč jsou chybné konfigurace autentizační vrstvy slabým místem AI nástrojů, viz Proč nástroje pro kódování s AI nechávají bezpečnostní mezery. Pro paralelní kontrolní seznam na Auth0 viz Kontrolní seznam zabezpečení Auth0.

Klíče prostředí a allowlist origins

Clerk vydává pro každý projekt dva odlišné klíče. Jejich míchání nebo úniky jsou prvním typem selhání.

Použijte publishable klíč (pk_live_* v produkci, pk_test_* v dev) v prohlížeči; secret klíč (sk_live_* / sk_test_*) pouze na serveru. Publishable klíč je bezpečný v NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret klíč nikdy nesmí nést veřejný env prefix a nikdy se nesmí objevit v klientské komponentě.
Ověřte, že produkční aplikace používá pk_live_*, nikoliv pk_test_*. Testovací instance povolují neověřené e-mailové adresy a vypnuté MFA — odeslání test mode do produkce je obejití autentizace.
Nakonfigurujte povolené origins v Clerk Dashboardu. Settings → Domains → Allowed origins musí přesně uvádět vaši produkční doménu. Prázdné seznamy nebo seznamy s wildcardem origin umožňují útočníkům vytvořit nelegální Clerk frontendy, které komunikují s vaším backendem.
Při odchodu nebo podezření na únik secret klíč rotujte. Dashboard → API Keys → Reset. Starý klíč je invalidován; před rotací znovu nasaďte kód na straně serveru s novou hodnotou.

Konfigurace relací

Expirace relace a doby nečinnosti jsou rozdílem mezi ukradenou relací jako 10minutovým incidentem a 30denním.

U SaaS aplikací zpracovávajících citlivá data nastavte timeout nečinnosti relace na 30 minut nebo méně. Dashboard → Sessions → Inactivity timeout. Aplikace bankovní úrovně by měly používat 5-10 minut; standardní SaaS 30-60 minut; spotřebitelské aplikace 1-7 dní. Výchozí hodnota je 7 dní.
Povolte odvolání relace při změně hesla, změně e-mailu a registraci MFA. Dashboard → Sessions → Revoke on. Toto jsou bezpečnostní události iniciované uživatelem; existující relace na jiných zařízeních by měly být zabity.
Ověřujte relace na straně serveru na každé chráněné trase, nejen při přihlášení. V Next.js: const { userId } = await auth(); v serverové komponentě / API trase přečte JWT z cookie a ověří ho. Nikdy nedůvěřujte kontrole pouze podle cookie.
Nastavte SameSite=Lax (výchozí) nebo Strict na session cookie. Ověřte v DevTools → Application → Cookies. SameSite=None je CSRF vektor — nikdy ho nepoužívejte, pokud jste explicitně nenakonfigurovali cross-domain auth nastavení.

Ověření webhooků

Webhooky Clerk se spouštějí na životních událostech uživatele (created, updated, deleted, session.ended). Jsou synchronizačním mechanismem pro vaši databázi — a podvržený webhook je primitivem pro zápis do databáze.

Ověřte podpis Svix u každého webhooku. Webhooky Clerk jsou podepsané Svix. Použijte new Webhook(secret).verify(body, headers). Pokud ověření selže, odmítněte s 401.
Tajemství webhooku uložte v proměnné prostředí, nikdy v kódu. Tajemství rotuje při každé regeneraci v Dashboardu — vaše nasazení ho musí číst z env, nikoliv z konstanty.
Idempotence na každém handleru. Doručení webhooku se mohou opakovat. Použijte hlavičku svix-id jako primární klíč v tabulce webhook_events k deduplikaci. Zabalte změnu stavu a vložení idempotence do stejné transakce.
Při user.deleted tvrdě smažte nebo anonymizujte PII do 24 hodin. GDPR / CCPA to vyžadují. Proveďte audit cesty mazání: které tabulky drží data tohoto uživatele? Použijte FK ON DELETE CASCADE, kde můžete.

Organizace a oprávnění

Pokud používáte Clerk Organizations, hranice org je vaší izolací nájemníků. Každý dotaz na straně serveru musí filtrovat podle ní.

Na každé API trase načtěte z auth() jak userId, tak orgId a filtrujte databázové dotazy podle obou. WHERE org_id = $orgId AND user_id = $userId. Nikdy nedůvěřujte org_id z těla požadavku.
<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.
Otestujte izolaci napříč org se dvěma skutečnými org účty. Vytvořte Org A, naplňte daty, přihlaste se do Org B v jiném prohlížeči, pokuste se přes API přečíst data Org A. Odpověď musí být 403 nebo 404.

JWT šablony a externí integrace

JWT šablony posunou identitu Clerk do Supabase, Firebase a dalších downstream služeb. Chybně nakonfigurované šablony nadměrně sdílejí nároky nebo vystavují data, která jste nezamýšleli.

U každé JWT šablony vypište každý nárok a potvrďte, že je nezbytný. Dashboard → JWT Templates. Šablona, která posílá email a phone do Supabase, vystavuje PII komukoliv, kdo přečte JWT v prohlížeči.
Nastavte krátkou expiraci na JWT šablonách používaných pro downstream volání na straně klienta. 60 sekund pro downstream API požadavky je standard. Dlouhotrvající JWT jsou kradeny a přehrávány.
Na přijímající straně ověřte nárok audience (aud). Supabase, Firebase atd. by měly zkontrolovat, že aud odpovídá očekávanému identifikátoru služby. Bez toho může JWT vydaný pro službu A autentizovat ke službě B.

Operační monitoring

Autentizace je zdrojem logů s nejvyšším signálem, který máte. Sledujte ji.

Alertujte na špičky neúspěšných přihlášení podle IP / podle účtu. 50× normální míra selhání je credential-stuffing útok. Clerk tyto události vysílá do webhooků; směrujte je do svého SIEM.
Čtvrtletní revize driftu nastavení relací a instance. Výchozí hodnoty se mění s aktualizacemi Clerk; "staré konfigurace" se časem tiše stávají špatnými. Porovnejte JSON export Dashboardu s vaší poslední známou dobrou kopií.

Další kroky

Spusťte FixVibe sken proti vaší produkční URL — kontrola baas.clerk-auth0 hlásí Clerk publishable klíče, test klíče v produkci a secret klíče v balíčku. Pro ekvivalentní kontrolní seznam na Auth0 viz Kontrolní seznam zabezpečení Auth0. Pro zastřešující pohled napříč poskytovateli BaaS si přečtěte Skener chybných konfigurací BaaS.