// docs / baas security / clerk hardening
چکلیست امنیت Clerk: ۲۰ مورد
Clerk احراز هویت، نشستها و سازمانها را برای اپلیکیشن شما مدیریت میکند — یعنی یک یکپارچهسازی Clerk با پیکربندی نادرست یک bypass احراز هویت، یک بردار تثبیت نشست یا یک مسیر نشت org است. این چکلیست یک ممیزی ۲۰ موردی در سراسر کلیدها، پیکربندی نشست، webhookها، سازمانها، قالبهای JWT و پایش جاری است. ابزارهای کدنویسی هوش مصنوعی Clerk را بهسرعت با پیشفرضهای معقول راهاندازی میکنند؛ این فهرست مواردی را که آنها روی میز میگذارند میگیرد.
برای پسزمینه درباره اینکه چرا پیکربندیهای نادرست لایه احراز هویت یک نقطه ضعف ابزار هوش مصنوعی هستند، چرا ابزارهای کدنویسی هوش مصنوعی شکافهای امنیتی به جای میگذارند را ببینید. برای چکلیست موازی روی Auth0، چکلیست امنیت Auth0 را ببینید.
کلیدهای محیط و allowlist origin
Clerk دو کلید متمایز بهازای هر پروژه صادر میکند. ترکیب کردن یا نشت آنها اولین حالت شکست است.
- از کلید publishable (
pk_live_*در تولید،pk_test_*در dev) در مرورگر استفاده کنید؛ از کلید secret (sk_live_*/sk_test_*) فقط در سرور استفاده کنید. کلید publishable درNEXT_PUBLIC_CLERK_PUBLISHABLE_KEYامن است؛ کلید secret هرگز نباید پیشوند env عمومی داشته باشد و هرگز نباید در یک کامپوننت کلاینت ظاهر شود. - تأیید کنید که اپلیکیشن تولیدی از
pk_live_*استفاده میکند، نهpk_test_*. نمونههای آزمایشی به آدرسهای ایمیل تأییدنشده و MFA غیرفعال اجازه میدهند — شحن حالت آزمایشی به تولید یک bypass احراز هویت است. - originهای مجاز را در داشبورد Clerk پیکربندی کنید. Settings → Domains → Allowed origins باید دامنه تولید شما را دقیقاً فهرست کند. فهرستهای origin خالی یا با wildcard به مهاجمان اجازه میدهد فرانتاندهای جعلی Clerk بسازند که با بکاند شما صحبت کنند.
- کلید secret را در هر خروج یا نشت مشکوک چرخش دهید. Dashboard → API Keys → Reset. کلید قدیمی بیاعتبار میشود؛ کد سمت سرور را با مقدار جدید پیش از چرخش دوباره مستقر کنید.
پیکربندی نشست
انقضای نشست و timeoutهای idle تفاوت بین یک نشست دزدیدهشده که یک حادثه ۱۰ دقیقهای است و یک حادثه ۳۰ روزه است.
- timeout غیرفعال نشست را روی ۳۰ دقیقه یا کمتر برای اپلیکیشنهای SaaS که دادههای حساس را مدیریت میکنند تنظیم کنید. Dashboard → Sessions → Inactivity timeout. اپلیکیشنهای سطح بانکی باید از ۵-۱۰ دقیقه استفاده کنند؛ SaaS استاندارد ۳۰-۶۰ دقیقه؛ اپلیکیشنهای مصرفکننده ۱-۷ روز. پیشفرض ۷ روز است.
- ابطال نشست را در تغییر گذرواژه، تغییر ایمیل و ثبتنام MFA فعال کنید. Dashboard → Sessions → Revoke on. اینها رویدادهای امنیتی شروعشده توسط کاربر هستند؛ نشستهای موجود روی دستگاههای دیگر باید کشته شوند.
- نشستها را در سمت سرور روی هر مسیر محافظتشده، نه فقط در ورود، تأیید کنید. در Next.js:
const { userId } = await auth();در یک کامپوننت سرور / مسیر API JWT را از کوکی میخواند و آن را اعتبارسنجی میکند. هرگز به یک بررسی فقط-کوکی اعتماد نکنید. SameSite=Lax(پیشفرض) یاStrictرا روی کوکی نشست تنظیم کنید. در DevTools → Application → Cookies تأیید کنید.SameSite=Noneیک بردار CSRF است — هرگز از آن استفاده نکنید مگر اینکه بهصراحت یک راهاندازی احراز هویت cross-domain را پیکربندی کردهاید.
تأیید webhook
webhookهای Clerk روی رویدادهای چرخه عمر کاربر (created، updated، deleted، session.ended) فعال میشوند. آنها مکانیزم همگامسازی برای پایگاهداده شما هستند — و یک webhook جعلی یک ابزار اولیه نوشتن در پایگاهداده است.
- امضای Svix را روی هر webhook تأیید کنید. webhookهای Clerk توسط Svix امضا میشوند. از
new Webhook(secret).verify(body, headers)استفاده کنید. اگر تأیید شکست خورد با401رد کنید. - secret webhook را در یک متغیر محیطی ذخیره کنید، هرگز در کد. secret در هر بازتولید داشبورد چرخش میکند — استقرار شما باید آن را از env بخواند، نه از یک ثابت.
- Idempotency در هر handler. تحویل webhookها میتوانند تکرار شوند. از هدر
svix-idبهعنوان کلید اصلی در یک جدولwebhook_eventsبرای deduplication استفاده کنید. تغییر state و درج idempotency را در یک تراکنش بپیچید. - روی
user.deleted، PII را در عرض ۲۴ ساعت hard-delete یا ناشناس کنید. GDPR / CCPA آن را نیاز دارند. مسیر حذف را ممیزی کنید: کدام جدولها دادههای این کاربر را نگه میدارند؟ از FK ON DELETE CASCADE در جایی که میتوانید استفاده کنید.
سازمانها و مجوزها
اگر از Clerk Organizations استفاده میکنید، مرز org ایزولاسیون مستأجر شماست. هر کوئری سمت سرور باید با آن فیلتر شود.
- روی هر مسیر API، هر دو
userIdوorgIdرا ازauth()بخوانید و کوئریهای پایگاهداده را با هر دو فیلتر کنید.WHERE org_id = $orgId AND user_id = $userId. هرگز به یکorg_idاز body درخواست اعتماد نکنید. - <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.
- ایزولاسیون cross-org را با دو حساب org واقعی آزمایش کنید. Org A را ایجاد کنید، داده پر کنید، در مرورگر دیگری به Org B وارد شوید، تلاش کنید دادههای Org A را از طریق API بخوانید. پاسخ باید
403یا404باشد.
قالبهای JWT و یکپارچهسازیهای خارجی
قالبهای JWT هویت Clerk را به Supabase، Firebase و سایر سرویسهای downstream میفرستند. قالبهای با پیکربندی نادرست claimها را بیش از حد به اشتراک میگذارند یا دادهای را که قصد نداشتید افشا میکنند.
- برای هر قالب JWT، هر claim را فهرست کنید و تأیید کنید لازم است. Dashboard → JWT Templates. یک قالب که
emailوphoneرا به Supabase میفرستد، PII را به هر کسی که JWT را در مرورگر میخواند افشا میکند. - روی قالبهای JWT که برای فراخوانیهای downstream سمت کلاینت استفاده میشوند انقضای کوتاه تنظیم کنید. ۶۰ ثانیه برای درخواستهای API downstream استاندارد است. JWTهای با عمر طولانیتر دزدیده و دوباره پخش میشوند.
- claim audience (
aud) را در سمت گیرنده تأیید کنید. Supabase، Firebase و غیره باید بررسی کنند کهaudبا شناسه سرویس مورد انتظار مطابقت دارد. بدون این، یک JWT صادرشده برای سرویس A میتواند به سرویس B احراز هویت کند.
پایش عملیاتی
احراز هویت بالاترین منبع سیگنال لاگ است که دارید. آن را تماشا کنید.
- روی جهشهای ورود ناموفق بهازای IP / بهازای حساب هشدار بدهید. یک نرخ شکست ۵۰× نرمال یک حمله credential-stuffing است. Clerk این رویدادها را به webhookها منتشر میکند؛ آنها را به SIEM خود مسیریابی کنید.
- بررسی فصلی انحراف تنظیمات نشست و نمونه. پیشفرضها با بهروزرسانیهای Clerk تغییر میکنند؛ "پیکربندیهای قدیمی" در طول زمان بیصدا اشتباه میشوند. صادرات JSON داشبورد را در برابر آخرین کپی شناختهشده خوب diff کنید.
گامهای بعدی
یک اسکن FixVibe را روی URL تولیدی خود اجرا کنید — فحص baas.clerk-auth0 کلیدهای publishable Clerk، کلیدهای آزمایشی در تولید و کلیدهای secret بستهبندیشده را علامتگذاری میکند. برای چکلیست معادل روی Auth0، چکلیست امنیت Auth0 را ببینید. برای دیدگاه چتری در میان ارائهدهندگان BaaS، اسکنر پیکربندی نادرست BaaS را بخوانید.