// docs / baas security / clerk hardening

Clerk-sikkerhedstjekliste: 20 punkter

Clerk håndterer auth, sessioner og organisationer for din app — hvilket betyder, at en fejlkonfigureret Clerk-integration er en auth-bypass, en session-fixation-vektor eller en org-lækagesti. Denne tjekliste er en 20-punkts revision på tværs af nøgler, sessionskonfiguration, webhooks, organisationer, JWT-skabeloner og igangværende overvågning. AI-kodeværktøjer kobler Clerk hurtigt med fornuftige standarder; denne liste fanger de punkter, de efterlader på bordet.

For baggrund om, hvorfor auth-lag-fejlkonfigurationer er et svagt punkt for AI-værktøjer, se Hvorfor AI-kodeværktøjer efterlader sikkerhedshuller. For den parallelle tjekliste på Auth0, se Auth0-sikkerhedstjekliste.

Miljønøgler og oprindelses-allowlist

Clerk udsteder to forskellige nøgler per projekt. At blande dem eller lække dem er den første fejltilstand.

Brug den publicerbare nøgle (pk_live_* i produktion, pk_test_* i udvikling) i browseren; brug den hemmelige nøgle (sk_live_* / sk_test_*) kun på serveren. Den publicerbare nøgle er sikker i NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; den hemmelige nøgle må aldrig bære et offentligt env-præfiks og må aldrig optræde i en klientkomponent.
Verificer, at produktionsappen bruger pk_live_*, ikke pk_test_*. Testinstanser tillader uverificerede e-mailadresser og deaktiveret MFA — at sende test-mode til produktion er en auth-bypass.
Konfigurer de tilladte oprindelser i Clerk Dashboard. Settings → Domains → Allowed origins skal angive dit produktionsdomæne præcist. Tomme eller wildcard-oprindelseslister lader angribere oprette rogue Clerk-frontends, der taler med din backend.
Roter den hemmelige nøgle ved enhver afgang eller mistænkt lækage. Dashboard → API Keys → Reset. Gammel nøgle ugyldiggøres; redeploy server-side kode med den nye værdi før rotation.

Sessionskonfiguration

Sessionens udløb og inaktivitetstimeout er forskellen mellem at en stjålet session er en 10-minutters hændelse og en 30-dages.

Sæt session-inaktivitetstimeout til 30 minutter eller mindre for SaaS-apps, der håndterer følsomme data. Dashboard → Sessions → Inactivity timeout. Banking-tier-apps bør bruge 5-10 minutter; standard SaaS 30-60 minutter; forbrugerapps 1-7 dage. Standarden er 7 dage.
Aktiver session-tilbagekaldelse ved adgangskodeændring, e-mailændring og MFA-tilmelding. Dashboard → Sessions → Revoke on. Disse er brugerinitierede sikkerhedshændelser; eksisterende sessioner på andre enheder skal dræbes.
Verificer sessioner server-side på hver beskyttet rute, ikke kun ved sign-in. I Next.js: const { userId } = await auth(); i en server-komponent / API-rute læser JWT'en fra cookien og validerer den. Stol aldrig på et cookie-kun-tjek.
Sæt SameSite=Lax (standard) eller Strict på sessionscookien. Verificer i DevTools → Application → Cookies. SameSite=None er en CSRF-vektor — brug den aldrig, medmindre du eksplicit har konfigureret en cross-domain auth-opsætning.

Webhook-verifikation

Clerk-webhooks affyres på bruger-livscyklus-hændelser (created, updated, deleted, session.ended). De er synkroniseringsmekanismen for din database — og en forfalsket webhook er en database-skrive-primitiv.

Verificer Svix-signaturen på hver webhook. Clerk-webhooks signeres af Svix. Brug new Webhook(secret).verify(body, headers). Afvis med 401, hvis verifikation fejler.
Opbevar webhook-hemmeligheden i en miljøvariabel, aldrig i koden. Hemmeligheden roterer ved hver Dashboard-regenerering — din deploy skal læse den fra env, ikke fra en konstant.
Idempotens på hver handler. Webhook-leverancer kan gentages. Brug svix-id-headeren som en primær nøgle i en webhook_events-tabel for at deduplikere. Indpak tilstandsændringen og idempotensindsættelsen i den samme transaktion.
Ved user.deleted, hard-slet eller anonymiser PII inden for 24 timer. GDPR / CCPA kræver det. Revider sletningsstien: hvilke tabeller har denne brugers data? Brug FK ON DELETE CASCADE, hvor du kan.

Organisationer og rettigheder

Hvis du bruger Clerk Organizations, er org-grænsen din tenant-isolation. Hver server-side forespørgsel skal filtrere på den.

På hver API-rute, læs både userId og orgId fra auth() og filtrer databaseforespørgsler på begge. WHERE org_id = $orgId AND user_id = $userId. Stol aldrig på et org_id fra request-bodyen.
<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.
Test cross-org-isolation med to ægte org-konti. Opret Org A, populer data, log ind på Org B i en anden browser, forsøg at læse Org A's data via API'en. Svar skal være 403 eller 404.

JWT-skabeloner og eksterne integrationer

JWT-skabeloner skubber Clerk-identitet ind i Supabase, Firebase og andre downstream-tjenester. Fejlkonfigurerede skabeloner overdeler claims eller eksponerer data, du ikke mente.

For hver JWT-skabelon, list hvert claim og bekræft, at det er nødvendigt. Dashboard → JWT Templates. En skabelon, der sender email og phone til Supabase, eksponerer PII til enhver, der læser JWT'en i browseren.
Sæt kort udløb på JWT-skabeloner brugt til client-side downstream-kald. 60 sekunder for downstream-API-anmodninger er standarden. Længere-levende JWT'er bliver stjålet og afspillet igen.
Verificer audience (aud)-claimet på modtagersiden. Supabase, Firebase osv. bør tjekke, at aud matcher den forventede tjenesteidentifikator. Uden dette kan en JWT udstedt til tjeneste A autentificere til tjeneste B.

Operationel overvågning

Auth er den højest-signalerende logkilde, du har. Hold øje med den.

Alarmér på mislykkede-login-spidser per IP / per konto. En 50× normal fejlrate er et credential-stuffing-angreb. Clerk udsender disse hændelser til webhooks; rut dem til dit SIEM.
Kvartalsvis gennemgang af session- og instansindstillingsdrift. Standarder ændrer sig, efterhånden som Clerk opdaterer; "gamle konfigurationer" bliver lydløst forkerte over tid. Diff Dashboard JSON-eksporten mod din sidst-kendt-gode kopi.

Næste skridt

Kør en FixVibe-scanning mod din produktions-URL — baas.clerk-auth0-checken markerer Clerk publicerbare nøgler, testnøgler i produktion og bundlede hemmelige nøgler. For den tilsvarende tjekliste på Auth0, se Auth0-sikkerhedstjekliste. For paraplyvisningen på tværs af BaaS-udbydere, læs BaaS-fejlkonfigurationsscanner.