// docs / baas security / clerk hardening

Кантрольны спіс бяспекі Clerk: 20 пунктаў

Clerk апрацоўвае аўтэнтыфікацыю, сесіі і арганізацыі для вашай праграмы — гэта азначае, што няправільна наладжаная інтэграцыя Clerk — гэта абыход аўтэнтыфікацыі, вектар фіксацыі сесіі або шлях уцечкі арганізацыі. Гэты кантрольны спіс — гэта аўдыт з 20 пунктаў па ключах, канфігурацыі сесіі, вэбхуках, арганізацыях, шаблонах JWT і пастаянным маніторынгу. ШІ-інструменты кадавання падключаюць Clerk хутка з разумнымі значэннямі па змаўчанні; гэты спіс ловіць пункты, якія яны пакідаюць на стале.

Для фону пра тое, чаму няправільныя налады пласта аўтэнтыфікацыі — гэта слабое месца ШІ-інструментаў, гл. Чаму ШІ-інструменты кадавання пакідаюць прабелы ў бяспецы. Для паралельнага кантрольнага спісу па Auth0 гл. Кантрольны спіс бяспекі Auth0.

Ключы асяроддзя і спіс дазволу origin

Clerk выдае два розныя ключы на праект. Іх змешванне або ўцечка — гэта першы рэжым адмовы.

Выкарыстоўвайце публікаваны ключ (pk_live_* у прадакшэне, pk_test_* у dev) у браўзеры; выкарыстоўвайце сакрэтны ключ (sk_live_* / sk_test_*) толькі на серверы. Публікаваны ключ бяспечны ў NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; сакрэтны ключ ніколі не павінен несці публічны прэфікс env і ніколі не павінен з'яўляцца ў кліенцкім кампаненце.
Праверце, што прадукцыйная праграма выкарыстоўвае pk_live_*, а не pk_test_*. Тэставыя інстансы дазваляюць непацверджаныя адрасы электроннай пошты і адключаны MFA — адпраўка тэставага рэжыму ў прадакшэн — гэта абыход аўтэнтыфікацыі.
Наладзьце дазволеныя origin у панэлі Clerk. Settings → Domains → Allowed origins павінны пералічваць ваш прадукцыйны дамен дакладна. Пустыя або падстаноўныя спісы origin дазваляюць зламыснікам ствараць падробленыя фронтэнды Clerk, якія размаўляюць з вашым бэкэндам.
Ратуйце сакрэтны ключ пры любым сыходзе або падазраванай уцечцы. Dashboard → API Keys → Reset. Стары ключ анулюецца; перавыпускайце серверны код з новым значэннем перад ратацыяй.

Канфігурацыя сесіі

Тэрмін дзеяння сесіі і час прастою — гэта розніца паміж тым, што скрадзеная сесія — гэта 10-хвілінны інцыдэнт або 30-дзённы.

Усталюйце тайм-аўт неактыўнасці сесіі на 30 хвілін або менш для SaaS-праграм, якія апрацоўваюць адчувальныя дадзеныя. Dashboard → Sessions → Inactivity timeout. Праграмы банкаўскага ўзроўню павінны выкарыстоўваць 5-10 хвілін; стандартны SaaS 30-60 хвілін; спажывецкія праграмы 1-7 дзён. Па змаўчанні — 7 дзён.
Уключыце адклік сесіі пры змене пароля, змене электроннай пошты і ўключэнні MFA. Dashboard → Sessions → Revoke on. Гэта карыстальніцкія падзеі бяспекі; існуючыя сесіі на іншых прыладах павінны быць забіты.
Правярайце сесіі на серверы на кожным абароненым маршруце, а не толькі пры ўваходзе. У Next.js: const { userId } = await auth(); у серверным кампаненце / API-маршруце чытае JWT з кукі і правярае яго. Ніколі не давярайце праверцы толькі па кукі.
Усталюйце SameSite=Lax (па змаўчанні) або Strict на кукі сесіі. Праверце ў DevTools → Application → Cookies. SameSite=None — гэта CSRF-вектар — ніколі не выкарыстоўвайце яго, калі вы відавочна не наладзілі крос-дамэнавую аўтэнтыфікацыю.

Праверка вэбхукаў

Вэбхукі Clerk спрацоўваюць на падзеях жыццёвага цыклу карыстальніка (створаны, абноўлены, выдалены, session.ended). Яны з'яўляюцца механізмам сінхранізацыі вашай базы дадзеных — і падроблены вэбхук — гэта прымітыў запісу ў базу дадзеных.

Правярайце подпіс Svix на кожным вэбхуку. Вэбхукі Clerk падпісаныя Svix. Выкарыстоўвайце new Webhook(secret).verify(body, headers). Адхіляйце з 401, калі праверка правальваецца.
Захоўвайце сакрэт вэбхука ў пераменнай асяроддзя, ніколі ў кодзе. Сакрэт ратуецца пры кожнай рэгенерацыі ў панэлі — ваша разгортванне павінна чытаць яго з env, а не з канстанты.
Ідэмпатэнтнасць на кожным апрацоўшчыку. Дастаўкі вэбхукаў могуць паўтарацца. Выкарыстоўвайце загаловак svix-id як першасны ключ у табліцы webhook_events для дэдуплікацыі. Загарніце змену стану і ўстаўку ідэмпатэнтнасці ў адну транзакцыю.
На user.deleted жорстка выдаляйце або ананімізуйце PII на працягу 24 гадзін. GDPR / CCPA патрабуюць гэтага. Праверце шлях выдалення: якія табліцы трымаюць дадзеныя гэтага карыстальніка? Выкарыстоўвайце FK ON DELETE CASCADE, дзе можаце.

Арганізацыі і дазволы

Калі вы выкарыстоўваеце арганізацыі Clerk, мяжа арганізацыі — гэта ваша ізаляцыя арэндатара. Кожны серверны запыт павінен фільтравацца па ёй.

На кожным API-маршруце чытайце як userId, так і orgId з auth() і фільтруйце запыты да базы дадзеных па абодвух. WHERE org_id = $orgId AND user_id = $userId. Ніколі не давярайце org_id з цела запыту.
<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.
Тэстуйце міжарганізацыйную ізаляцыю з двума рэальнымі акаўнтамі арганізацыі. Стварыце Org A, запоўніце дадзенымі, увайдзіце ў Org B у іншым браўзеры, паспрабуйце прачытаць дадзеныя Org A праз API. Адказ павінен быць 403 або 404.

Шаблоны JWT і знешнія інтэграцыі

Шаблоны JWT перадаюць ідэнтычнасць Clerk у Supabase, Firebase і іншыя downstream-сэрвісы. Няправільна наладжаныя шаблоны падзяляюць занадта шмат патрабаванняў або раскрываюць дадзеныя, якія вы не мелі на ўвазе.

Для кожнага шаблону JWT пералічыце кожнае патрабаванне і пацвердзіце, што яно неабходнае. Dashboard → JWT Templates. Шаблон, які адпраўляе email і phone у Supabase, раскрывае PII любому, хто чытае JWT у браўзеры.
Усталюйце кароткі тэрмін дзеяння на шаблоны JWT, якія выкарыстоўваюцца для кліенцкіх downstream-выклікаў. 60 секунд для downstream API-запытаў — гэта стандарт. Доўгажывучыя JWT крадуць і прайграваюць.
Правярайце патрабаванне аўдыторыі (aud) на прымаючым баку. Supabase, Firebase і г. д. павінны правяраць, што aud адпавядае чаканаму ідэнтыфікатару сэрвісу. Без гэтага JWT, выдадзены для сэрвісу A, можа аўтэнтыфікавацца ў сэрвіс B.

Эксплуатацыйны маніторынг

Аўтэнтыфікацыя — гэта крыніца логаў з самым высокім сігналам, якая ў вас ёсць. Сачыце за ёй.

Папярэджвайце пра ўсплёскі няўдалых уваходаў на IP / на акаўнт. 50-кратная нармальная хуткасць адмоваў — гэта атака credential stuffing. Clerk адпраўляе гэтыя падзеі ў вэбхукі; накіроўвайце іх у ваш SIEM.
Штоквартальны агляд дрэйфу налад сесіі і інстансу. Значэнні па змаўчанні мяняюцца, калі Clerk абнаўляецца; "старыя канфігурацыі" ціха становяцца няправільнымі з часам. Параўнайце JSON-экспарт панэлі з вашай апошняй вядома-добрай копіяй.

Наступныя крокі

Запусціце сканаванне FixVibe супраць вашага прадукцыйнага URL — праверка baas.clerk-auth0 пазначае публікаваныя ключы Clerk, тэставыя ключы ў прадакшэне і пастаўленыя ў бандл сакрэтныя ключы. Для эквівалентнага кантрольнага спісу па Auth0 гл. Кантрольны спіс бяспекі Auth0. Для агульнага агляду па пастаўшчыках BaaS прачытайце Сканер няправільных налад BaaS.