// docs / baas security / clerk hardening

Clerk güvenlik kontrol listesi: 20 madde

Clerk uygulamanız için auth, oturumları ve organizasyonları yönetir — bu, yanlış yapılandırılmış bir Clerk entegrasyonunun bir auth bypass'i, bir oturum sabitleme vektörü veya bir org sızıntı yolu olduğu anlamına gelir. Bu kontrol listesi anahtarlar, oturum yapılandırması, webhook'lar, organizasyonlar, JWT şablonları ve sürekli izleme konularında 20 maddelik bir denetimdir. Yapay zeka kodlama araçları Clerk'i mantıklı varsayılanlarla hızlı bir şekilde bağlar; bu liste onların masaya bıraktığı maddeleri yakalar.

Auth katmanı yanlış yapılandırmalarının neden bir yapay zeka aracı zayıf noktası olduğuna dair arka plan için Yapay zeka kodlama araçları neden güvenlik açıkları bırakır bölümüne bakın. Auth0'daki paralel kontrol listesi için Auth0 güvenlik kontrol listesi'ne bakın.

Ortam anahtarları ve origin allowlist'i

Clerk her proje için iki farklı anahtar verir. Bunları karıştırmak veya sızdırmak ilk başarısızlık modudur.

Tarayıcıda yayınlanabilir anahtarı (üretimde pk_live_*, geliştirmede pk_test_*); sunucuda yalnızca gizli anahtarı (sk_live_* / sk_test_*) kullanın. Yayınlanabilir anahtar NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY içinde güvenlidir; gizli anahtar asla bir public env öneki taşımamalı ve asla bir istemci bileşeninde görünmemelidir.
Üretim uygulamasının pk_test_* değil pk_live_* kullandığını doğrulayın. Test instance'ları doğrulanmamış e-posta adreslerine ve devre dışı bırakılmış MFA'ya izin verir — test modunu üretime göndermek bir auth bypass'idir.
Clerk Dashboard'da izin verilen origin'leri yapılandırın. Settings → Domains → Allowed origins üretim domain'inizi tam olarak listelemelidir. Boş veya joker origin listeleri, saldırganların backend'inizle konuşan sahte Clerk frontend'leri oluşturmasına izin verir.
Herhangi bir ayrılık veya şüpheli sızıntıda gizli anahtarı döndürün. Dashboard → API Keys → Reset. Eski anahtar geçersizleştirilir; rotasyon yapmadan önce sunucu tarafı kodu yeni değerle yeniden dağıtın.

Oturum yapılandırması

Oturum süre dolumu ve boşta zaman aşımları, çalınan bir oturumun 10 dakikalık bir olay mı yoksa 30 günlük bir olay mı olduğunun farkıdır.

Hassas veri işleyen SaaS uygulamaları için oturum boşta zaman aşımını 30 dakika veya daha az olarak ayarlayın. Dashboard → Sessions → Inactivity timeout. Banka düzeyindeki uygulamalar 5-10 dakika; standart SaaS 30-60 dakika; tüketici uygulamaları 1-7 gün kullanmalıdır. Varsayılan 7 gündür.
Parola değişikliği, e-posta değişikliği ve MFA kaydında oturum iptalini etkinleştirin. Dashboard → Sessions → Revoke on. Bunlar kullanıcı tarafından başlatılan güvenlik olaylarıdır; diğer cihazlardaki mevcut oturumlar sonlandırılmalıdır.
Sadece oturum açışta değil, her korumalı rotada sunucu tarafında oturumları doğrulayın. Next.js'de: bir sunucu bileşeni / API rotasında const { userId } = await auth(); JWT'yi çerezden okur ve doğrular. Asla yalnızca çerez kontrolüne güvenmeyin.
Oturum çerezinde SameSite=Lax (varsayılan) veya Strict ayarlayın. DevTools → Application → Cookies'te doğrulayın. SameSite=None bir CSRF vektörüdür — açıkça etki alanlar arası bir auth kurulumu yapılandırmadığınız sürece asla kullanmayın.

Webhook doğrulama

Clerk webhook'ları kullanıcı yaşam döngüsü olaylarında (created, updated, deleted, session.ended) tetiklenir. Bunlar veritabanınız için senkronizasyon mekanizmasıdır — ve sahte bir webhook bir veritabanı yazma primitive'idir.

Her webhook'ta Svix imzasını doğrulayın. Clerk webhook'ları Svix tarafından imzalanır. new Webhook(secret).verify(body, headers) kullanın. Doğrulama başarısız olursa 401 ile reddedin.
Webhook secret'ını bir ortam değişkeninde saklayın, asla kod içinde değil. Secret her Dashboard yenilemesinde döner — deployment'ınız onu env'den okumalı, bir sabitten değil.
Her işleyicide idempotency. Webhook teslimatları tekrarlayabilir. Tekrarları engellemek için bir webhook_events tablosunda birincil anahtar olarak svix-id başlığını kullanın. Durum değişikliğini ve idempotency eklemeyi aynı işleme sarın.
user.deleted'ta 24 saat içinde PII'yi sert silme veya anonimleştirme. GDPR / CCPA bunu gerektirir. Silme yolunu denetleyin: hangi tablolar bu kullanıcının verisini tutuyor? Mümkün olduğunda FK ON DELETE CASCADE kullanın.

Organizasyonlar ve izinler

Clerk Organizations kullanıyorsanız, org sınırı kiracı izolasyonunuzdur. Her sunucu tarafı sorgu ona göre filtrelemelidir.

Her API rotasında auth()'tan hem userId hem de orgId'yi okuyun ve veritabanı sorgularını ikisine göre filtreleyin. WHERE org_id = $orgId AND user_id = $userId. İstek gövdesinden gelen bir org_id'ye asla güvenmeyin.
<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.
İki gerçek org hesabıyla orglar arası izolasyonu test edin. Org A'yı oluşturun, veri doldurun, başka bir tarayıcıda Org B'ye oturum açın, API üzerinden Org A'nın verilerini okumayı deneyin. Yanıt 403 veya 404 olmalıdır.

JWT şablonları ve harici entegrasyonlar

JWT şablonları Clerk kimliğini Supabase, Firebase ve diğer aşağı akış hizmetlerine iter. Yanlış yapılandırılmış şablonlar fazla claim paylaşır veya kastetmediğiniz verileri ifşa eder.

Her JWT şablonu için her claim'i listeleyin ve gerekli olduğunu teyit edin. Dashboard → JWT Templates. Supabase'e email ve phone gönderen bir şablon, tarayıcıdaki JWT'yi okuyan herkese PII ifşa eder.
İstemci tarafı aşağı akış çağrıları için kullanılan JWT şablonlarında kısa son kullanma tarihi ayarlayın. Aşağı akış API istekleri için standart 60 saniyedir. Daha uzun ömürlü JWT'ler çalınır ve yeniden oynatılır.
Alıcı tarafta audience (aud) claim'ini doğrulayın. Supabase, Firebase vb. aud'un beklenen hizmet tanımlayıcısıyla eşleştiğini kontrol etmelidir. Bu olmadan, A hizmeti için verilen bir JWT B hizmetinde kimlik doğrulayabilir.

Operasyonel izleme

Auth sahip olduğunuz en yüksek sinyalli log kaynağıdır. İzleyin.

IP başına / hesap başına başarısız oturum açma artışlarında uyarı verin. Normal başarısızlık oranının 50 katı bir credential stuffing saldırısıdır. Clerk bu olayları webhook'lara yayınlar; bunları SIEM'inize yönlendirin.
Üç ayda bir oturum ve instance ayar sürüklenmesini inceleyin. Clerk güncellendikçe varsayılanlar değişir; "eski yapılandırmalar" zamanla sessizce yanlış hale gelir. Dashboard JSON ihracatını son bilinen iyi kopyanıza karşı fark alın.

Sonraki adımlar

Üretim URL'nize karşı bir FixVibe taraması çalıştırın — baas.clerk-auth0 kontrolü Clerk yayınlanabilir anahtarlarını, üretimdeki test anahtarlarını ve paketlenmiş gizli anahtarları işaretler. Auth0'daki eşdeğer kontrol listesi için Auth0 güvenlik kontrol listesi'ne bakın. BaaS sağlayıcıları arasındaki şemsiye görünüm için BaaS yanlış yapılandırma tarayıcısı bölümünü okuyun.