FixVibe

// docs / baas security / clerk hardening

Clerk қауіпсіздік тізімі: 20 тармақ

Clerk сіздің қолданбаңыз үшін аутентификация, сеанстар және ұйымдарды басқарады — бұл қате конфигурацияланған Clerk интеграциясы аутентификация айналуы, сеанс-бекіту векторы немесе ұйым-ағу жолы екенін білдіреді. Бұл тізім — кілттер, сеанс конфигурациясы, вебхуктар, ұйымдар, JWT үлгілері және үздіксіз бақылау бойынша 20 тармақты аудит. ИИ кодтау құралдары Clerk-ті ақылды әдепкі мәндермен тез қосады; бұл тізім олар үстелде қалдыратын тармақтарды ұстайды.

Аутентификация қабатының қате конфигурацияларының неге ИИ-құрал әлсіз жері екенінің фондық ақпараты үшін ИИ кодтау құралдары неге қауіпсіздік олқылықтарын қалдырады қараңыз. Auth0-да параллель тізім үшін Auth0 қауіпсіздік тізімі қараңыз.

Орта кілттері және шығу тегі ақ тізімі

Clerk жоба бойынша екі бөлек кілт шығарады. Оларды араластыру немесе ағызу — бірінші сәтсіздік режимі.

  1. Браузерде жариялау кілтін (өндірісте pk_live_*, әзірлеуде pk_test_*) пайдаланыңыз; серверде ғана құпия кілтті (sk_live_* / sk_test_*) пайдаланыңыз. Жариялау кілті NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY ішінде қауіпсіз; құпия кілт ешқашан жалпыға ортақ env префиксін көтермеуі керек және ешқашан клиент компонентінде пайда болмауы керек.
  2. Өндіріс қолданбасы pk_test_* емес, pk_live_* пайдаланатынын тексеріңіз. Тест даналары расталмаған электрондық пошта мекенжайларына және өшірілген MFA-ға рұқсат береді — өндіріске тест режимін жіберу — аутентификация айналуы.
  3. Clerk бақылау тақтасында рұқсат етілген шығу тегін конфигурациялаңыз. Settings → Domains → Allowed origins сіздің өндіріс доменіңізді нақты тізуі керек. Бос немесе джокер шығу тегі тізімдері шабуылдаушыларға бэкендіңізбен сөйлесетін жалған Clerk алдыңғы жақтарын жасауға мүмкіндік береді.
  4. Кету немесе ағу күмән болғанда құпия кілтті айналдырыңыз. Бақылау тақтасы → API Keys → Reset. Ескі кілт жарамсыз болады; айналдыруға дейін жаңа мәнмен сервер жағындағы кодты қайта орналастырыңыз.

Сеанс конфигурациясы

Сеанс аяқталу мерзімі және әрекетсіз күту мерзімдері — ұрланған сеанс 10 минуттық оқиға немесе 30 күндік оқиға болуының арасындағы айырмашылық.

  1. Сезімтал деректерді өңдейтін SaaS қолданбалары үшін сеанс әрекетсіздік мерзімін 30 минут немесе одан аз етіңіз. Бақылау тақтасы → Sessions → Inactivity timeout. Банк деңгейіндегі қолданбалар 5-10 минут пайдалануы керек; стандартты SaaS 30-60 минут; тұтынушы қолданбалары 1-7 күн. Әдепкі — 7 күн.
  2. Құпиясөзді өзгерту, электрондық поштаны өзгерту және MFA тіркелуінде сеанс қайтарып алуды қосыңыз. Бақылау тақтасы → Sessions → Revoke on. Бұлар — пайдаланушы бастаған қауіпсіздік оқиғалары; басқа құрылғылардағы бар сеанстар жойылуы керек.
  3. Сеанстарды әр қорғалған бағытта сервер жағында тексеріңіз, тек кіруде емес. Next.js ішінде: серверлік компонентте / API бағытында const { userId } = await auth(); cookie-ден JWT оқып, оны тексереді. Тек cookie тексеруіне ешқашан сенбеңіз.
  4. Сеанс cookie-де SameSite=Lax (әдепкі) немесе Strict орнатыңыз. DevTools → Application → Cookies ішінде тексеріңіз. SameSite=None — CSRF векторы — кросс-домен auth орнатуын анық конфигурацияламасаңыз ешқашан пайдаланбаңыз.

Вебхук тексеруі

Clerk вебхуктары пайдаланушы өмір циклі оқиғаларында (жасалды, жаңартылды, жойылды, session.ended) іске қосылады. Олар сіздің дерекқорыңыз үшін синхрондау механизмі — және жалған вебхук — дерекқор-жазу примитиві.

  1. Әр вебхукта Svix қолтаңбасын тексеріңіз. Clerk вебхуктарына Svix қол қояды. new Webhook(secret).verify(body, headers) пайдаланыңыз. Тексеру сәтсіз болса 401 арқылы қабылдамаңыз.
  2. Вебхук құпиясын кодта емес, орта айнымалысында сақтаңыз. Құпия әр бақылау тақтасы қайта генерациясында айналады — сіздің орналастыруыңыз оны env-тен оқуы керек, тұрақтыдан емес.
  3. Әр өңдеушіде идемпотенттік. Вебхук жеткізулері қайталануы мүмкін. Дубликатсыздыққа арналған webhook_events кестесінде svix-id тақырыбын негізгі кілт ретінде пайдаланыңыз. Күй өзгерісі мен идемпотенттік кірістіруді бір транзакцияға орап алыңыз.
  4. user.deleted кезінде 24 сағат ішінде PII-ні қатаң жойыңыз немесе анонимдеңіз. GDPR / CCPA оны талап етеді. Жою жолын аудиттеңіз: қандай кестелер осы пайдаланушының деректерін ұстайды? Жасай алатын жерде FK ON DELETE CASCADE пайдаланыңыз.

Ұйымдар және рұқсаттар

Clerk ұйымдарын пайдалансаңыз, ұйым шекарасы — сіздің жалгер оқшаулауыңыз. Әр сервер жағындағы сұрау сол арқылы сүзгілеуі керек.

  1. Әр API бағытында auth() ішінен userId және orgId екеуін де оқып, дерекқор сұрауларын екеуімен сүзгілеңіз. WHERE org_id = $orgId AND user_id = $userId. Ешқашан сұрау денесінен org_id мәніне сенбеңіз.
  2. <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.
  3. Кросс-ұйым оқшаулауын екі нақты ұйым тіркелгісімен тексеріңіз. A ұйымын жасап, деректермен толтырыңыз, басқа браузерде B ұйымына кіріп, API арқылы A ұйымының деректерін оқып көріңіз. Жауап 403 немесе 404 болуы керек.

JWT үлгілері және сыртқы интеграциялар

JWT үлгілері Clerk идентификациясын Supabase, Firebase және басқа төменгі ағынды қызметтерге итереді. Қате конфигурацияланған үлгілер талаптарды артық бөліседі немесе сіз көрсеткіңіз келмеген деректерді ашады.

  1. Әр JWT үлгісі үшін әр талапты тізіп, оның қажет екенін растаңыз. Бақылау тақтасы → JWT Templates. Supabase-ке email және phone жіберетін үлгі браузерде JWT-ны оқитын кез келген адамға PII ашады.
  2. Клиенттік төменгі ағынды шақырулар үшін пайдаланылатын JWT үлгілерінде қысқа аяқталу мерзімін орнатыңыз. Төменгі ағынды API сұраулары үшін 60 секунд — стандарт. Ұзақ өмір сүретін JWT-лер ұрланып, қайта ойналады.
  3. Қабылдау жағында аудитория (aud) талабын тексеріңіз. Supabase, Firebase және т.б. aud күтілетін қызмет идентификаторымен сәйкес келетінін тексеруі керек. Онсыз A қызметі үшін шығарылған JWT B қызметіне аутентификациялана алады.

Операциялық бақылау

Аутентификация — сізге қол жетімді ең жоғары сигнал журнал көзі. Оны қараңыз.

  1. IP / тіркелгі бойынша сәтсіз-кіру секірулеріне ескерту беріңіз. Қалыпты сәтсіздік жылдамдығынан 50× — тіркелгі деректерін толтыру шабуылы. Clerk бұл оқиғаларды вебхуктарға шығарады; оларды SIEM-ге бағыттаңыз.
  2. Сеанс және дана параметрлерінің ауысуын тоқсан сайын қарап шығу. Clerk жаңартқан сайын әдепкі мәндер өзгереді; "ескі конфигурациялар" уақыт өте келе үнсіз қате болады. Бақылау тақтасы JSON экспортын соңғы белгілі-жақсы көшірмемен айырыңыз.

Келесі қадамдар

Өндіріс URL мекенжайыңызға қарсы FixVibe сканерлеуін іске қосыңыз — baas.clerk-auth0 тексеруі Clerk жариялау кілттерін, өндірістегі тест кілттерін және бумалы құпия кілттерді белгілейді. Auth0-да параллель тізім үшін Auth0 қауіпсіздік тізімі қараңыз. BaaS провайдерлерінен шатыр көрінісі үшін BaaS қате конфигурациясының сканері оқыңыз.

// baas бетіңізді сканерлеңіз

Ашық кестені біреу одан бұрын тапқанша табыңыз.

Өндіріс URL мекенжайын енгізіңіз. FixVibe сіздің қолданбаңыз сөйлесетін BaaS провайдерлерін санайды, олардың жалпыға ортақ соңғы нүктелерінің саусақ ізін алады және аутентификацияланбаған клиент не оқи немесе жаза алатынын хабарлайды. Тегін, орнатусыз, картасыз.

  • Тегін деңгей — айына 3 сканерлеу, тіркелу картасы жоқ.
  • Пассивті BaaS саусақ ізін алу — домен иелігін растау қажет емес.
  • Supabase, Firebase, Clerk, Auth0, Appwrite және басқалары.
  • Әр табылған нәтижеде ИИ түзету шақырулары — Cursor / Claude Code ішіне қайта қойыңыз.
Clerk қауіпсіздік тізімі: 20 тармақ — Docs · FixVibe