// docs / baas security / clerk hardening

Checklist keamanan Clerk: 20 item

Clerk menangani auth, sesi, dan organisasi untuk aplikasi Anda — yang berarti integrasi Clerk yang salah konfigurasi adalah bypass auth, vektor fiksasi sesi, atau jalur kebocoran org. Checklist ini adalah audit 20-item lintas key, konfigurasi sesi, webhook, organisasi, template JWT, dan pemantauan berkelanjutan. AI coding tools menyiapkan Clerk dengan cepat dengan default yang masuk akal; daftar ini menangkap item yang mereka tinggalkan.

Untuk latar belakang mengapa miskonfigurasi lapisan auth adalah titik lemah AI-tooling, lihat Mengapa AI coding tools meninggalkan celah keamanan. Untuk checklist paralel di Auth0, lihat Checklist keamanan Auth0.

Key environment dan allowlist origin

Clerk menerbitkan dua key berbeda per proyek. Mencampurnya atau membocorkannya adalah mode kegagalan pertama.

Gunakan publishable key (pk_live_* di produksi, pk_test_* di dev) di browser; gunakan secret key (sk_live_* / sk_test_*) hanya di server. Publishable key aman di NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret key tidak boleh pernah membawa prefix env publik dan tidak pernah muncul di komponen klien.
Verifikasi aplikasi produksi menggunakan pk_live_*, bukan pk_test_*. Instans test mengizinkan alamat email yang belum diverifikasi dan MFA yang dinonaktifkan — mengirimkan mode test ke produksi adalah bypass auth.
Konfigurasikan origin yang diizinkan di Clerk Dashboard. Settings → Domains → Allowed origins harus mencantumkan domain produksi Anda secara persis. Daftar origin kosong atau wildcard memungkinkan penyerang membuat frontend Clerk nakal yang berbicara dengan backend Anda.
Rotasi secret key pada kepergian apa pun atau kecurigaan kebocoran. Dashboard → API Keys → Reset. Key lama diinvalidasi; deploy ulang kode sisi server dengan nilai baru sebelum merotasi.

Konfigurasi sesi

Kadaluarsa sesi dan timeout idle adalah perbedaan antara sesi yang dicuri menjadi insiden 10 menit dan 30 hari.

Set timeout inaktivitas sesi ke 30 menit atau kurang untuk aplikasi SaaS yang menangani data sensitif. Dashboard → Sessions → Inactivity timeout. Aplikasi tingkat perbankan harus menggunakan 5-10 menit; SaaS standar 30-60 menit; aplikasi konsumen 1-7 hari. Default adalah 7 hari.
Aktifkan pencabutan sesi pada perubahan password, perubahan email, dan pendaftaran MFA. Dashboard → Sessions → Revoke on. Ini adalah peristiwa keamanan yang diprakarsai user; sesi yang ada di perangkat lain harus dimatikan.
Verifikasi sesi di sisi server pada setiap route yang dilindungi, bukan hanya saat sign-in. Di Next.js: const { userId } = await auth(); di server component / API route membaca JWT dari cookie dan memvalidasinya. Jangan pernah mempercayai pemeriksaan hanya-cookie.
Set SameSite=Lax (default) atau Strict pada cookie sesi. Verifikasi di DevTools → Application → Cookies. SameSite=None adalah vektor CSRF — jangan pernah gunakan kecuali Anda telah secara eksplisit mengonfigurasi pengaturan auth lintas-domain.

Verifikasi webhook

Webhook Clerk dipicu pada peristiwa siklus hidup user (created, updated, deleted, session.ended). Mereka adalah mekanisme sinkronisasi untuk database Anda — dan webhook palsu adalah primitif tulis-database.

Verifikasi tanda tangan Svix pada setiap webhook. Webhook Clerk ditandatangani oleh Svix. Gunakan new Webhook(secret).verify(body, headers). Tolak dengan 401 jika verifikasi gagal.
Simpan secret webhook di environment variable, tidak pernah di kode. Secret berotasi pada setiap regenerasi Dashboard — deploy Anda harus membacanya dari env, bukan dari konstanta.
Idempotensi pada setiap handler. Pengiriman webhook dapat berulang. Gunakan header svix-id sebagai primary key di tabel webhook_events untuk dedup. Bungkus perubahan state dan insert idempotensi dalam transaksi yang sama.
Pada user.deleted, hapus keras atau anonimkan PII dalam 24 jam. GDPR / CCPA memerlukannya. Audit jalur penghapusan: tabel mana yang menyimpan data user ini? Gunakan FK ON DELETE CASCADE di mana Anda bisa.

Organisasi dan izin

Jika Anda menggunakan Clerk Organizations, batas org adalah isolasi tenant Anda. Setiap query sisi server harus difilter olehnya.

Pada setiap route API, baca baik userId maupun orgId dari auth() dan filter query database berdasarkan keduanya. WHERE org_id = $orgId AND user_id = $userId. Jangan pernah mempercayai org_id dari body request.
<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.
Uji isolasi lintas-org dengan dua akun org nyata. Buat Org A, isi data, masuk ke Org B di browser lain, coba baca data Org A via API. Response harus 403 atau 404.

Template JWT dan integrasi eksternal

Template JWT mendorong identitas Clerk ke Supabase, Firebase, dan layanan hilir lainnya. Template yang salah konfigurasi berbagi claim yang berlebihan atau mengekspos data yang tidak Anda maksudkan.

Untuk setiap template JWT, daftar setiap claim dan konfirmasi itu perlu. Dashboard → JWT Templates. Template yang mengirim email dan phone ke Supabase mengekspos PII kepada siapa saja yang membaca JWT di browser.
Set kadaluarsa pendek pada template JWT yang digunakan untuk panggilan hilir sisi klien. 60 detik untuk request API hilir adalah standar. JWT yang berumur lebih lama dicuri dan diputar ulang.
Verifikasi claim audience (aud) di sisi penerima. Supabase, Firebase, dll. harus memeriksa bahwa aud cocok dengan pengenal layanan yang diharapkan. Tanpa ini, JWT yang diterbitkan untuk layanan A dapat berautentikasi ke layanan B.

Pemantauan operasional

Auth adalah sumber log dengan sinyal tertinggi yang Anda miliki. Pantaulah.

Beri peringatan pada lonjakan login gagal per IP / per akun. Tingkat kegagalan 50× normal adalah serangan credential stuffing. Clerk mengeluarkan peristiwa-peristiwa ini ke webhook; arahkan ke SIEM Anda.
Tinjauan kuartalan terhadap pergeseran pengaturan sesi dan instans. Default berubah seiring update Clerk; "konfigurasi lama" diam-diam menjadi salah seiring waktu. Diff ekspor JSON Dashboard terhadap salinan terkenal-baik terakhir Anda.

Langkah berikutnya

Jalankan scan FixVibe terhadap URL produksi Anda — check baas.clerk-auth0 menandai publishable key Clerk, key test di produksi, dan secret key yang ter-bundle. Untuk checklist setara di Auth0, lihat Checklist keamanan Auth0. Untuk tinjauan menyeluruh lintas penyedia BaaS, baca Scanner miskonfigurasi BaaS.