// docs / baas security / clerk hardening

Clerk-sikkerhetssjekkliste: 20 punkter

Clerk håndterer auth, økter og organisasjoner for appen din — noe som betyr at en feilkonfigurert Clerk-integrasjon er en auth-omgåelse, en økt-fiksjonsvektor eller en org-lekkasjesti. Denne sjekklisten er en 20-punkts gransking på tvers av nøkler, økt-konfigurasjon, webhooks, organisasjoner, JWT-maler og løpende overvåking. AI-kodeverktøy kobler opp Clerk raskt med fornuftige standarder; denne listen fanger punktene de lar bli liggende på bordet.

For bakgrunn om hvorfor feilkonfigurasjoner i auth-laget er et svakt punkt for AI-verktøy, se Hvorfor AI-kodeverktøy etterlater sikkerhetshull. For den tilsvarende sjekklisten for Auth0, se Auth0-sikkerhetssjekkliste.

Miljønøkler og origin-allowlist

Clerk utsteder to distinkte nøkler per prosjekt. Å blande dem eller lekke dem er den første feilmodusen.

Bruk den publiserbare nøkkelen (pk_live_* i produksjon, pk_test_* i dev) i nettleseren; bruk hemmelig nøkkel (sk_live_* / sk_test_*) kun på serveren. Den publiserbare nøkkelen er trygg i NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; hemmelig nøkkel må aldri bære et offentlig env-prefiks og må aldri vises i en klientkomponent.
Verifiser at produksjonsappen bruker pk_live_*, ikke pk_test_*. Testinstanser tillater uverifiserte e-postadresser og deaktivert MFA — å levere testmodus til produksjon er en auth-omgåelse.
Konfigurer de tillatte origins i Clerk Dashboard. Settings → Domains → Allowed origins må liste produksjonsdomenet ditt nøyaktig. Tomme eller wildcard-origin-lister lar angripere opprette uautoriserte Clerk-frontends som snakker med backenden din.
Roter hemmelig nøkkel ved enhver avgang eller mistenkt lekkasje. Dashboard → API Keys → Reset. Den gamle nøkkelen invalideres; redeploy serverside-kode med den nye verdien før rotering.

Økt-konfigurasjon

Økt-utløp og inaktivitets-timeouts er forskjellen mellom at en stjålet økt er en 10-minutters hendelse og en 30-dagers.

Sett økt-inaktivitets-timeout til 30 minutter eller mindre for SaaS-apper som håndterer sensitive data. Dashboard → Sessions → Inactivity timeout. Bank-nivå-apper bør bruke 5–10 minutter; standard SaaS 30–60 minutter; forbrukerapper 1–7 dager. Standard er 7 dager.
Aktiver økt-tilbakekall ved passordendring, e-postendring og MFA-registrering. Dashboard → Sessions → Revoke on. Dette er brukerinitierte sikkerhetshendelser; eksisterende økter på andre enheter bør avsluttes.
Verifiser økter serverside på hver beskyttet rute, ikke bare ved innlogging. I Next.js: const { userId } = await auth(); i en serverkomponent / API-rute leser JWT-en fra cookien og validerer den. Stol aldri på en cookie-bare-sjekk.
Sett SameSite=Lax (standard) eller Strict på økt-cookien. Verifiser i DevTools → Application → Cookies. SameSite=None er en CSRF-vektor — bruk den aldri med mindre du eksplisitt har konfigurert et cross-domain-auth-oppsett.

Webhook-verifisering

Clerk-webhooks utløses ved livssyklushendelser for brukere (created, updated, deleted, session.ended). De er synkroniseringsmekanismen for databasen din — og en forfalsket webhook er en database-skriveprimitiv.

Verifiser Svix-signaturen på hver webhook. Clerk-webhooks signeres av Svix. Bruk new Webhook(secret).verify(body, headers). Avvis med 401 hvis verifiseringen mislykkes.
Lagre webhook-hemmeligheten i en miljøvariabel, aldri i kode. Hemmeligheten roteres ved hver Dashboard-regenerering — deployen din må lese den fra env, ikke fra en konstant.
Idempotens på hver handler. Webhook-leveranser kan gjentas. Bruk svix-id-headeren som primærnøkkel i en webhook_events-tabell for å deduplikere. Pakk tilstandsendringen og idempotens-inserten i samme transaksjon.
Ved user.deleted, hard-slett eller anonymiser PII innen 24 timer. GDPR/CCPA krever det. Gransk slettestien: hvilke tabeller holder denne brukerens data? Bruk FK ON DELETE CASCADE der du kan.

Organisasjoner og rettigheter

Hvis du bruker Clerk Organizations, er org-grensen din tenant-isolering. Hver serverside-spørring må filtrere etter den.

På hver API-rute, les både userId og orgId fra auth() og filtrer databasespørringer etter begge. WHERE org_id = $orgId AND user_id = $userId. Stol aldri på en 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 isolering på tvers av orgs med to ekte org-kontoer. Opprett Org A, fyll inn data, logg inn på Org B i en annen nettleser, prøv å lese Org As data via API-et. Svaret må være 403 eller 404.

JWT-maler og eksterne integrasjoner

JWT-maler dytter Clerk-identitet inn i Supabase, Firebase og andre nedstrømstjenester. Feilkonfigurerte maler deler for mange claims eller eksponerer data du ikke mente.

For hver JWT-mal, list opp hvert claim og bekreft at det er nødvendig. Dashboard → JWT Templates. En mal som sender email og phone til Supabase eksponerer PII til enhver som leser JWT-en i nettleseren.
Sett kort utløp på JWT-maler som brukes for nedstrømskall klientside. 60 sekunder for nedstrøms API-requests er standarden. Lengre-levende JWT-er blir stjålet og spilt av på nytt.
Verifiser audience-claimet (aud) på mottakersiden. Supabase, Firebase osv. bør sjekke at aud matcher den forventede tjenesteidentifikatoren. Uten dette kan en JWT utstedt for tjeneste A autentisere mot tjeneste B.

Operativ overvåking

Auth er den høyeste-signal loggkilden du har. Følg med på den.

Varsle om feilet-innloggings-topper per IP / per konto. En 50× normal feilrate er en credential-stuffing-angrep. Clerk sender disse hendelsene til webhooks; rut dem til SIEM-en din.
Kvartalsvis gjennomgang av drift i økt- og instansinnstillinger. Standarder endres når Clerk oppdaterer; "gamle konfigurasjoner" blir stille feil over tid. Diff Dashboardets JSON-eksport mot din sist-kjente-gode kopi.

Neste steg

Kjør en FixVibe-skanning mot produksjons-URL-en din — baas.clerk-auth0-sjekken flagger Clerk publiserbare nøkler, testnøkler i produksjon og bundlede hemmelige nøkler. For den tilsvarende sjekklisten for Auth0, se Auth0-sikkerhetssjekkliste. For helhetsbildet på tvers av BaaS-leverandører, les BaaS-feilkonfigurasjonsskanner.