// docs / baas security / clerk hardening

Clerk-säkerhetschecklista: 20 punkter

Clerk hanterar auth, sessioner och organisationer för din app — vilket innebär att en felkonfigurerad Clerk-integration är ett auth-kringgående, en session-fixation-vektor eller en org-läckagestig. Den här checklistan är en 20-punkts granskning över nycklar, session-konfiguration, webhooks, organisationer, JWT-mallar och löpande övervakning. AI-kodningsverktyg kopplar upp Clerk snabbt med vettiga defaults; den här listan fångar punkterna de lämnar på bordet.

För bakgrund till varför auth-lagrets felkonfigurationer är en svag punkt för AI-verktyg, se Varför AI-kodningsverktyg lämnar säkerhetsluckor. För motsvarande checklista för Auth0, se Auth0-säkerhetschecklista.

Miljönycklar och origin-allowlist

Clerk utfärdar två distinkta nycklar per projekt. Att blanda dem eller läcka dem är det första felläget.

Använd den publicerbara nyckeln (pk_live_* i produktion, pk_test_* i dev) i webbläsaren; använd secret-nyckeln (sk_live_* / sk_test_*) enbart på servern. Den publicerbara nyckeln är säker i NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret-nyckeln får aldrig bära ett publikt env-prefix och får aldrig visas i en klientkomponent.
Verifiera att produktionsappen använder pk_live_*, inte pk_test_*. Testinstanser tillåter overifierade e-postadresser och inaktiverad MFA — att leverera testläge till produktion är ett auth-kringgående.
Konfigurera de tillåtna origins i Clerk-dashboarden. Settings → Domains → Allowed origins måste lista din produktionsdomän exakt. Tomma eller wildcard-origin-listor låter angripare skapa skurkaktiga Clerk-frontends som pratar med din backend.
Rotera secret-nyckeln vid varje avgång eller misstänkt läcka. Dashboard → API Keys → Reset. Gammal nyckel invalideras; deploya serverkod med det nya värdet innan rotation.

Session-konfiguration

Session-förfall och idle timeouts är skillnaden mellan att en stulen session är en 10-minuters incident och en 30-dagars.

Sätt session-inaktivitets-timeout till 30 minuter eller mindre för SaaS-appar som hanterar känslig data. Dashboard → Sessions → Inactivity timeout. Bankvärdiga appar bör använda 5–10 minuter; standard-SaaS 30–60 minuter; konsumentappar 1–7 dagar. Default är 7 dagar.
Aktivera session-revokering vid lösenordsbyte, e-postbyte och MFA-registrering. Dashboard → Sessions → Revoke on. Det här är användarinitierade säkerhetshändelser; existerande sessioner på andra enheter ska dödas.
Verifiera sessioner serverside på varje skyddad rutt, inte bara vid inloggning. I Next.js: const { userId } = await auth(); i en serverkomponent / API-rutt läser JWT:n från cookien och validerar den. Lita aldrig på en cookie-bara-kontroll.
Sätt SameSite=Lax (default) eller Strict på session-cookien. Verifiera i DevTools → Application → Cookies. SameSite=None är en CSRF-vektor — använd den aldrig om du inte explicit har konfigurerat en cross-domain-auth-uppsättning.

Webhook-verifiering

Clerk-webhooks avfyras på användarlivscykelhändelser (created, updated, deleted, session.ended). De är synkroniseringsmekanismen för din databas — och en förfalskad webhook är en databasskriv-primitiv.

Verifiera Svix-signaturen på varje webhook. Clerk-webhooks signeras av Svix. Använd new Webhook(secret).verify(body, headers). Avvisa med 401 om verifieringen misslyckas.
Lagra webhook-hemligheten i en miljövariabel, aldrig i kod. Hemligheten roteras vid varje dashboard-regenerering — din deploy måste läsa den från env, inte från en konstant.
Idempotens på varje handler. Webhook-leveranser kan upprepas. Använd svix-id-headern som primärnyckel i en webhook_events-tabell för att deduplicera. Linda in tillståndsändringen och idempotens-inserten i samma transaktion.
Vid user.deleted, hård-radera eller anonymisera PII inom 24 timmar. GDPR/CCPA kräver det. Granska borttagningsstigen: vilka tabeller håller den här användarens data? Använd FK ON DELETE CASCADE där du kan.

Organisationer och behörigheter

Om du använder Clerk Organizations är org-gränsen din tenant-isolering. Varje serverside-fråga måste filtrera på den.

På varje API-rutt, läs både userId och orgId från auth() och filtrera databasfrågor på båda. WHERE org_id = $orgId AND user_id = $userId. Lita aldrig på ett org_id från request-bodyn.
<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.
Testa korsorganisationsisolering med två riktiga org-konton. Skapa org A, fyll i data, logga in på org B i en annan webbläsare, försök läsa org A:s data via API:t. Svaret måste vara 403 eller 404.

JWT-mallar och externa integrationer

JWT-mallar pushar Clerk-identitet in i Supabase, Firebase och andra nedströmstjänster. Felkonfigurerade mallar överdelar claims eller exponerar data du inte avsåg.

För varje JWT-mall, lista varje claim och bekräfta att den är nödvändig. Dashboard → JWT Templates. En mall som skickar email och phone till Supabase exponerar PII för vem som helst som läser JWT:n i webbläsaren.
Sätt kort förfall på JWT-mallar som används för klientsides nedströmsanrop. 60 sekunder för nedströms-API-förfrågningar är standard. Längre levande JWT:er stjäls och spelas upp igen.
Verifiera audience-claimen (aud) på mottagarsidan. Supabase, Firebase, etc. bör kontrollera att aud matchar den förväntade tjänsteidentifieraren. Utan detta kan en JWT utfärdad för tjänst A autentisera mot tjänst B.

Operativ övervakning

Auth är den högsta-signal-loggkälla du har. Bevaka den.

Larma vid misslyckade-inloggnings-spikar per IP / per konto. En 50× normal felfrekvens är en credential-stuffing-attack. Clerk skickar dessa händelser till webhooks; ruta dem till ditt SIEM.
Kvartalsvis granskning av drift i session- och instansinställningar. Defaults ändras när Clerk uppdaterar; "gamla konfigurationer" blir tyst fel över tid. Diffa dashboardens JSON-export mot din senast-kända-bra-kopia.

Nästa steg

Kör en FixVibe-scanning mot din produktions-URL — baas.clerk-auth0-checken flaggar Clerk publicerbara nycklar, testnycklar i produktion och buntade secret-nycklar. För motsvarande checklista för Auth0, se Auth0-säkerhetschecklista. För helhetsbilden över BaaS-leverantörer, läs BaaS-felkonfigurationsscanner.