// docs / baas security / clerk hardening

Clerk segurtasun-zerrenda: 20 elementu

Clerk-ek zure aplikaziorako autentifikazioa, saioak eta erakundeak kudeatzen ditu — eta horrek esan nahi du Clerk integrazio gaizki konfiguratu bat autentifikazio-saihespena, saio-finkatzeko bektorea edo erakunde-iragazketako bidea dela. Zerrenda hau gako, saio-konfigurazio, webhook, erakunde, JWT-txantiloi eta jarraian dauden monitorizazioei buruzko 20 elementuko auditoretza bat da. IA kodetze-tresnek Clerk azkar konektatzen dute lehenetsi zentzudunekin; zerrenda honek mahaian uzten dituzten elementuak harrapatzen ditu.

Autenten-mailako konfigurazio okerrak IA-tresnen ahultasuna zergatik diren ikusteko atzeko, ikus Zergatik IA kodetze-tresnek segurtasun-hutsuneak uzten dituzten. Auth0-en paraleloko zerrenda ikusteko, ikus Auth0 segurtasun-zerrenda.

Ingurune-gakoak eta jatorri-baimen-zerrenda

Clerk-ek bi gako desberdin igortzen ditu proiektu bakoitzeko. Horiek nahastea edo iragaztea lehenengo hutsegite-modua da.

Erabili gako argitaragarria (pk_live_* ekoizpenean, pk_test_* dev-en) nabigatzailean; erabili gako sekretua (sk_live_* / sk_test_*) zerbitzarian soilik. Gako argitaragarria segurua da NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY-n; gako sekretuak ez du inoiz publiko ingurune-aurrizkirik eraman behar eta ez da inoiz bezero-osagai batean agertu behar.
Egiaztatu ekoizpen-aplikazioak pk_live_* erabiltzen duela, ez pk_test_*. Proba-instantziek egiaztatu gabeko helbide elektronikoak eta desgaitutako MFA baimentzen dituzte — proba modua ekoizpenera bidaltzea autentifikazio-saihespena da.
Konfiguratu baimendutako jatorriak Clerk aginte-panelean. Settings → Domains → Allowed origins-ek zure ekoizpen-domeinua zehazki zerrendatu behar du. Hutsa edo komodineko jatorri-zerrendek erasotzaileei zure backend-arekin hitz egiten duten Clerk frontend bihurriak sortzeko aukera ematen die.
Biratu gako sekretua edozein joan edo susmagarri iragazpenean. Aginte-panela → API Keys → Reset. Gako zaharra baliogabetua dago; berriz zabaldu zerbitzariaren aldeko kodea balio berriarekin biratu aurretik.

Saio-konfigurazioa

Saio-iraungitzeak eta inaktibitate-denbora-mugak lapurtutako saio batek 10 minutuko gertaera edo 30 eguneko gertaera den arteko aldea dira.

Ezarri saio-inaktibitate denbora-muga 30 minutu edo gutxiagora datu sentikorrak kudeatzen dituzten SaaS aplikazioetarako. Aginte-panela → Sessions → Inactivity timeout. Banku-mailako aplikazioek 5-10 minutu erabili beharko lukete; SaaS estandarrak 30-60 minutu; kontsumitzaile-aplikazioak 1-7 egun. Lehenetsia 7 egun da.
Gaitu saio-baliogabetzea pasahitz-aldaketan, posta elektronikoa aldatzean eta MFA inskripzioan. Aginte-panela → Sessions → Revoke on. Hauek erabiltzaileak hasitako segurtasun-gertaerak dira; beste gailuetan dauden saioak hil egin behar dira.
Egiaztatu saioak zerbitzariaren aldetik babestutako bide bakoitzean, ez bakarrik saio-hasieran. Next.js-en: const { userId } = await auth(); server-osagai / API bide batean cookie-tik JWT-a irakurtzen du eta balioztatzen du. Inoiz ez fidatu cookie-soileko egiaztapen batez.
Ezarri SameSite=Lax (lehenetsia) edo Strict saio-cookie-an. Egiaztatu DevTools → Application → Cookies-en. SameSite=None CSRF bektore bat da — ez erabili sekula zeharkako autentifikazio-konfigurazio bat esplizituki konfiguratu duzun arte.

Webhook egiaztapena

Clerk webhook-ek erabiltzaileen bizitza-zikloko gertaeretan suntzen dira (sortua, eguneratua, ezabatua, session.ended). Zure datu-basearen sinkronizazio-mekanismoa dira — eta faltsifikatutako webhook bat datu-baseko idazketa-primitibo bat da.

Egiaztatu Svix sinadura webhook bakoitzean. Clerk webhook-ak Svix-ek sinatzen ditu. Erabili new Webhook(secret).verify(body, headers). Errefusatu 401-arekin egiaztapenak huts egiten badu.
Gorde webhook sekretua ingurune-aldagai batean, inoiz ez kodean. Sekretua aginte-panelaren birsorkuntza bakoitzean biratzen da — zure zabalpenak hura ingurunetik irakurri behar du, ez konstante batetik.
Idempotentzia kudeatzaile bakoitzean. Webhook entregak errepika daitezke. Erabili svix-id goiburua lehen gako gisa webhook_events taula batean bikoiztea kentzeko. Bildu egoera-aldaketa eta idempotentzia-txertaketa transakzio berean.
user.deleted-an, gogor ezabatu edo anonimizatu PII 24 orduen barruan. GDPR / CCPAk hala eskatzen dute. Auditatu ezabatze-bidea: zein taulek dauzkate erabiltzaile honen datuak? Erabili FK ON DELETE CASCADE ahal duzun lekuetan.

Erakundeak eta baimenak

Clerk Organizations erabiltzen baduzu, erakunde-muga zure maizter-bereizketa da. Zerbitzariaren aldeko kontsulta bakoitzak hor iragazi behar du.

API bide bakoitzean, irakurri bai userId bai orgId auth()-tik eta iragazi datu-baseko kontsultak biengatik. WHERE org_id = $orgId AND user_id = $userId. Ez fidatu inoiz eskaeraren gorputzeko org_id-az.
<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.
Proba zeharkako-erakunde bereizketa bi benetako erakunde-konturekin. Sortu A erakundea, bete datuak, eman izena B erakundean beste nabigatzaile batean, saiatu A erakundearen datuak APIaren bidez irakurtzen. Erantzunak 403 edo 404 izan behar du.

JWT txantiloiak eta kanpoko integrazioak

JWT txantiloiek Clerk identitatea Supabasera, Firebasera eta beste maila beheragoko zerbitzuetara bultzatzen dute. Gaizki konfiguratutako txantiloiek erreklamazio gehiegi partekatzen dituzte edo asmoz kanpoko datuak agerian uzten dituzte.

JWT txantiloi bakoitzeko, zerrendatu erreklamazio bakoitza eta egiaztatu beharrezkoa dela. Aginte-panela → JWT Templates. Supabasera email eta phone bidaltzen dituen txantiloi batek PII nabigatzailean JWT-a irakurtzen duen edonori agerian uzten dio.
Ezarri iraungitze laburra bezero-aldeko maila beheragoko deietarako erabiltzen diren JWT txantiloietan. 60 segundo maila beheragoko API eskaeretarako estandarra da. Bizitza luzeagoko JWT-ak lapurtu eta errepikatzen dira.
Egiaztatu audientzia (aud) erreklamazioa hartzaile aldean. Supabase, Firebase, etab. aud espero den zerbitzu-identifikatzailearekin bat datorrela egiaztatu beharko lukete. Hori gabe, A zerbitzurako igorritako JWT batek B zerbitzura autentifikatu dezake.

Monitorizazio operatiboa

Autentifikazioa duzun seinale altueneko erregistro-iturri da. Begiratu hari.

Alarmatu saio-hasiera huts gorakadetan IP / kontu bakoitzeko. Hutsegite-tasa normalaren 50× erasoa kredentzial-betetze eraso bat da. Clerk-ek gertaera horiek webhook-etara igortzen ditu; bideratu hauek zure SIEMera.
Hiruhilekoko berrikuspena saio eta instantzia ezarpenen jariotzeari. Lehenetsiak aldatzen dira Clerk eguneratzen denean; "konfigurazio zaharrak" isilean okerrak bilakatzen dira denboran zehar. Konparatu aginte-panelaren JSON esportazioa zure azken kopia ezagunarekin.

Hurrengo urratsak

Egin FixVibe eskaneatze bat zure ekoizpen-URLaren aurka — baas.clerk-auth0 egiaztapenak Clerk gako argitaragarriak, ekoizpenean dauden proba-gakoak eta bundle-eko gako sekretuak markatzen ditu. Auth0-en zerrenda baliokidea ikusteko, ikus Auth0 segurtasun-zerrenda. BaaS hornitzaileen ikuspegi orokorra ikusteko, irakurri BaaS konfigurazio okerren eskanerra.