// docs / baas security / clerk hardening

Clerk-beveiligingschecklist: 20 punten

Clerk regelt auth, sessies en organisaties voor je app — wat betekent dat een verkeerd geconfigureerde Clerk-integratie een auth-bypass, een sessie-fixatievector of een org-lekkagepad is. Deze checklist is een audit met 20 punten over sleutels, sessieconfiguratie, webhooks, organisaties, JWT-templates en doorlopende monitoring. AI-codeertools bedraden Clerk snel met redelijke standaardinstellingen; deze lijst vangt de items op die ze op tafel laten liggen.

Voor achtergrond over waarom auth-laag-misconfiguraties een zwak punt zijn voor AI-tooling, zie Waarom AI-codeertools beveiligingsgaten achterlaten. Voor de parallelle checklist op Auth0, zie Auth0-beveiligingschecklist.

Omgevingssleutels en oorsprong-allowlist

Clerk geeft twee verschillende sleutels uit per project. Ze mixen of lekken is de eerste faalmodus.

Gebruik de publiceerbare sleutel (pk_live_* in productie, pk_test_* in dev) in de browser; gebruik de geheime sleutel (sk_live_* / sk_test_*) alleen op de server. De publiceerbare sleutel is veilig in NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; de geheime sleutel mag nooit een openbaar env-voorvoegsel dragen en mag nooit in een clientcomponent verschijnen.
Verifieer dat de productie-app pk_live_* gebruikt, niet pk_test_*. Testinstanties staan onverifieerde e-mailadressen en uitgeschakelde MFA toe — het verzenden van testmodus naar productie is een auth-bypass.
Configureer de toegestane oorsprongen in het Clerk-dashboard. Instellingen → Domeinen → Toegestane oorsprongen moet je productiedomein exact vermelden. Lege of wildcard-oorsprongslijsten laten aanvallers schurkachtige Clerk-frontends maken die met je backend praten.
Roteer de geheime sleutel bij elk vertrek of vermoedelijke lek. Dashboard → API-sleutels → Reset. Oude sleutel is ongeldig; deploy server-side code opnieuw met de nieuwe waarde voordat je roteert.

Sessieconfiguratie

Sessievervaltijd en inactieve time-outs zijn het verschil tussen een gestolen sessie die een 10-minuten-incident is en een van 30 dagen.

Stel sessie-inactiviteits-time-out in op 30 minuten of minder voor SaaS-apps die met gevoelige data omgaan. Dashboard → Sessies → Inactiviteits-time-out. Banking-tier-apps moeten 5-10 minuten gebruiken; standaard SaaS 30-60 minuten; consumenten-apps 1-7 dagen. Standaard is 7 dagen.
Schakel sessie-intrekking in bij wachtwoordwijziging, e-mailwijziging en MFA-aanmelding. Dashboard → Sessies → Intrekken bij. Dit zijn door gebruikers geïnitieerde beveiligingsgebeurtenissen; bestaande sessies op andere apparaten moeten worden beëindigd.
Verifieer sessies server-side bij elke beschermde route, niet alleen bij het inloggen. In Next.js: const { userId } = await auth(); in een servercomponent / API-route leest de JWT uit de cookie en valideert deze. Vertrouw nooit een alleen-cookie-controle.
Stel SameSite=Lax (standaard) of Strict in op de sessiecookie. Verifieer in DevTools → Applicatie → Cookies. SameSite=None is een CSRF-vector — gebruik het nooit tenzij je expliciet een cross-domain auth-opstelling hebt geconfigureerd.

Webhook-verificatie

Clerk-webhooks vuren op gebruiker-levenscyclusgebeurtenissen (created, updated, deleted, session.ended). Ze zijn het synchronisatiemechanisme voor je database — en een vervalste webhook is een database-schrijfprimitief.

Verifieer de Svix-handtekening op elke webhook. Clerk-webhooks worden ondertekend door Svix. Gebruik new Webhook(secret).verify(body, headers). Weiger met 401 als verificatie mislukt.
Sla het webhook-geheim op in een omgevingsvariabele, nooit in code. Het geheim roteert bij elke regeneratie in het dashboard — je deployment moet het uit env lezen, niet uit een constante.
Idempotentie op elke handler. Webhook-leveringen kunnen zich herhalen. Gebruik de svix-id-header als primaire sleutel in een webhook_events-tabel om te dedupliceren. Wikkel de statuswijziging en de idempotentie-invoeging in dezelfde transactie.
Bij user.deleted, hard verwijderen of PII binnen 24 uur anonimiseren. GDPR / CCPA vereisen het. Audit het verwijderingspad: welke tabellen bevatten de data van deze gebruiker? Gebruik FK ON DELETE CASCADE waar je kunt.

Organisaties en permissies

Als je Clerk Organizations gebruikt, is de org-grens je tenant-isolatie. Elke server-side-query moet erop filteren.

Lees bij elke API-route zowel userId als orgId uit auth() en filter database-query's op beide. WHERE org_id = $orgId AND user_id = $userId. Vertrouw nooit een org_id uit de aanvraagbody.
<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-isolatie met twee echte org-accounts. Maak Org A, vul data, log in op Org B in een andere browser, probeer Org A's data te lezen via de API. Antwoord moet 403 of 404 zijn.

JWT-templates en externe integraties

JWT-templates pushen Clerk-identiteit naar Supabase, Firebase en andere downstream-diensten. Verkeerd geconfigureerde templates delen claims overmatig of leggen data bloot die je niet bedoelde.

Lijst voor elke JWT-template elke claim op en bevestig dat deze nodig is. Dashboard → JWT-templates. Een template die email en phone naar Supabase stuurt, stelt PII bloot aan iedereen die de JWT in de browser leest.
Stel een korte vervaltijd in op JWT-templates die worden gebruikt voor downstream-calls aan de clientzijde. 60 seconden voor downstream-API-aanvragen is de standaard. Langlevende JWT's worden gestolen en hergebruikt.
Verifieer de audience (aud)-claim aan de ontvangstzijde. Supabase, Firebase, enz. moeten controleren dat aud overeenkomt met de verwachte service-identifier. Zonder dit kan een JWT die is uitgegeven voor service A zich authenticeren bij service B.

Operationele monitoring

Auth is de hoogste-signaalogbron die je hebt. Houd het in de gaten.

Alert bij mislukte-login-pieken per IP / per account. Een 50× normale faalpercentage is een credential-stuffing-aanval. Clerk zendt deze gebeurtenissen uit naar webhooks; route ze naar je SIEM.
Kwartaalbeoordeling van sessie- en instantie-instellingsdrift. Standaardinstellingen veranderen naarmate Clerk wordt bijgewerkt; "oude configuraties" worden in de loop van de tijd stilletjes verkeerd. Diff de dashboard JSON-export tegen je laatst-bekende-goede kopie.

Volgende stappen

Voer een FixVibe-scan uit tegen je productie-URL — de baas.clerk-auth0-check markeert Clerk publiceerbare sleutels, testsleutels in productie en gebundelde geheime sleutels. Voor de equivalente checklist op Auth0, zie Auth0-beveiligingschecklist. Voor het paraplu-overzicht over BaaS-providers, lees BaaS-misconfiguratiescanner.