// docs / baas security / clerk hardening

Clerk-tietoturvatarkistuslista: 20 kohtaa

Clerk hoitaa sovelluksesi authentikoinnin, sessiot ja organisaatiot — mikä tarkoittaa, että virhekonfiguroitu Clerk-integraatio on auth-ohitus, session-fiksaatio-vektori tai org-vuotopolku. Tämä tarkistuslista on 20-kohdan tarkastus avaimien, session-konfiguraation, webhookien, organisaatioiden, JWT-templaattien ja jatkuvan valvonnan yli. AI-koodaustyökalut johdottavat Clerkin nopeasti järkevillä oletuksilla; tämä lista nappaa kohdat, jotka ne jättävät pöydälle.

Taustaksi siitä, miksi auth-kerroksen virhekonfiguraatiot ovat AI-työkalujen heikko kohta, katso Miksi AI-koodaustyökalut jättävät tietoturva-aukkoja. Vastaavaan tarkistuslistaan Auth0:lle katso Auth0-tietoturvatarkistuslista.

Ympäristöavaimet ja origin-allowlist

Clerk myöntää kaksi erillistä avainta projektia kohti. Niiden sekoittaminen tai vuotaminen on ensimmäinen vikatila.

Käytä julkaistavaa avainta (pk_live_* tuotannossa, pk_test_* kehityksessä) selaimessa; käytä secret-avainta (sk_live_* / sk_test_*) vain palvelimella. Julkaistava avain on turvallinen kohdassa NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret-avain ei saa koskaan kantaa julkista env-etuliitettä eikä koskaan esiintyä klienttikomponentissa.
Verifioi, että tuotantosovellus käyttää pk_live_*:ta, ei pk_test_*:ta. Testi-instanssit sallivat verifioimattomat sähköpostiosoitteet ja poistetun MFA:n — test moden lähettäminen tuotantoon on auth-ohitus.
Konfiguroi sallitut originit Clerk-dashboardissa. Settings → Domains → Allowed origins täytyy listata tuotantodomainisi täsmälleen. Tyhjät tai wildcard-origin-listat antavat hyökkääjien luoda väärennettyjä Clerk-frontendejä, jotka puhuvat backendisi kanssa.
Rotatoi secret-avain jokaisen lähdön tai epäillyn vuodon yhteydessä. Dashboard → API Keys → Reset. Vanha avain mitätöidään; julkaise palvelinpuolen koodi uudella arvolla ennen rotaatiota.

Session-konfiguraatio

Session-vanhentuminen ja jouten oloaikakatkokset ovat ero sen välillä, että varastettu sessio on 10 minuutin tapaus tai 30 päivän.

Aseta session-jouten-oloaikakatkokseksi 30 minuuttia tai vähemmän SaaS-sovelluksille, jotka käsittelevät arkaluonteista dataa. Dashboard → Sessions → Inactivity timeout. Pankki-tason sovellusten tulisi käyttää 5–10 minuuttia; standardi-SaaS 30–60 minuuttia; kuluttajasovellukset 1–7 päivää. Oletus on 7 päivää.
Ota session-mitätöinti käyttöön salasanan vaihdossa, sähköpostin vaihdossa ja MFA-rekisteröitymisessä. Dashboard → Sessions → Revoke on. Nämä ovat käyttäjälähtöisiä tietoturvatapahtumia; muilla laitteilla olevat olemassa olevat sessiot tulisi tappaa.
Verifioi sessiot palvelinpuolella jokaisella suojatulla reitillä, ei vain sisäänkirjautumisessa. Next.js:ssä: const { userId } = await auth(); palvelinkomponentissa/API-reitissä lukee JWT:n cookieista ja validoi sen. Älä koskaan luota pelkkään cookie-tarkistukseen.
Aseta SameSite=Lax (oletus) tai Strict session-cookieen. Verifioi DevToolsissa → Application → Cookies. SameSite=None on CSRF-vektori — älä koskaan käytä sitä, ellet ole eksplisiittisesti konfiguroinut ristidomain-auth-asetusta.

Webhookien verifiointi

Clerk-webhookit laukeavat käyttäjän elinkaaritapahtumissa (created, updated, deleted, session.ended). Ne ovat synkronisointimekanismi tietokantaasi varten — ja väärennetty webhook on tietokannan kirjoituspr-primitiivi.

Verifioi Svix-allekirjoitus jokaisessa webhookissa. Clerk-webhookit allekirjoitetaan Svixillä. Käytä new Webhook(secret).verify(body, headers):ia. Hylkää 401:llä, jos verifiointi epäonnistuu.
Tallenna webhook-secret ympäristömuuttujaan, älä koskaan koodiin. Secret rotatoituu jokaisen Dashboard-uudelleengeneroinnin yhteydessä — julkaisusi täytyy lukea se env:stä, ei vakiosta.
Idempotenssi jokaisessa käsittelijässä. Webhook-toimitukset voivat toistua. Käytä svix-id-headeria primääriavaimena webhook_events-taulussa dedupatiaksesi. Käärä tilamuutos ja idempotenssi-insertti samaan transaktioon.
Kohdassa user.deleted kovapoista tai anonymisoi PII 24 tunnin sisällä. GDPR/CCPA vaatii sen. Tarkasta poistopolku: mitkä taulut sisältävät tämän käyttäjän dataa? Käytä FK ON DELETE CASCADE -toimintoa missä voit.

Organisaatiot ja oikeudet

Jos käytät Clerk Organizations -toimintoa, org-raja on tenant-eristyksesi. Jokaisen palvelinpuolen kyselyn täytyy suodattaa sen mukaan.

Jokaisella API-reitillä lue sekä userId että orgId auth():sta ja suodata tietokantakyselyt molemmilla. WHERE org_id = $orgId AND user_id = $userId. Älä koskaan luota pyynnön rungossa olevaan org_id:hen.
<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.
Testaa ristikkäisorg-eristys kahdella todellisella org-tilillä. Luo Org A, täytä dataa, kirjaudu Org B:hen toisessa selaimessa, yritä lukea Org A:n dataa API:n kautta. Vastauksen täytyy olla 403 tai 404.

JWT-templaatit ja ulkoiset integraatiot

JWT-templaatit työntävät Clerk-identiteetin Supabaseen, Firebaseen ja muihin alavirran palveluihin. Virhekonfiguroidut templaatit jakavat liikaa claimeja tai paljastavat dataa, jota et tarkoittanut.

Jokaiselle JWT-templaatille listaa jokainen claim ja vahvista, että se on tarpeellinen. Dashboard → JWT Templates. Templaatti, joka lähettää email:n ja phone:n Supabaseen, paljastaa PII:tä kenelle tahansa, joka lukee JWT:n selaimessa.
Aseta lyhyt vanhentumisaika JWT-templaateille, joita käytetään klienttipuolen alavirran kutsuihin. 60 sekuntia alavirran API-pyyntöihin on standardi. Pidempi-elossa-olevat JWT:t varastetaan ja toistetaan.
Verifioi yleisö (aud)-claim vastaanottavalla puolella. Supabasen, Firebasen, jne. tulisi tarkistaa, että aud vastaa odotettua palvelutunnusta. Ilman tätä palvelulle A myönnetty JWT voi autentikoitua palveluun B.

Operatiivinen valvonta

Auth on korkeimman signaalin lokilähde, joka sinulla on. Pidä silmällä.

Hälytä epäonnistuneiden sisäänkirjautumisten piikeistä per IP / per tili. 50× normaali epäonnistumistaajuus on credential-stuffing-hyökkäys. Clerk lähettää nämä tapahtumat webhookeihin; reititä ne SIEMiisi.
Neljännesvuosittainen katsaus session- ja instanssi-asetusten ajautumiseen. Oletukset muuttuvat Clerk-päivitysten myötä; "vanhat konfiguraatiot" muuttuvat hiljaa vääriksi ajan myötä. Diffaa Dashboard-JSON-vienti viimeisimpään hyvään kopioosi.

Seuraavat askeleet

Aja FixVibe-skannaus tuotanto-URL:ääsi vastaan — baas.clerk-auth0-tarkistus lippuu Clerk-julkaistavat-avaimet, tuotannossa olevat testiavaimet ja paketoidut secret-avaimet. Vastaavaan tarkistuslistaan Auth0:lle katso Auth0-tietoturvatarkistuslista. Kokonaisnäkymää varten BaaS-tarjoajien yli lue BaaS-virhekonfiguraatioskanneri.