// docs / baas security / clerk hardening
Контролен списък за сигурност на Clerk: 20 точки
Clerk управлява auth, сесии и организации за вашето приложение — което означава, че неправилно конфигурирана интеграция с Clerk е заобикаляне на автентикацията, вектор за session-fixation или път за изтичане на org данни. Този контролен списък е одит от 20 точки на ключове, конфигурация на сесии, webhooks, организации, JWT темплейти и текущ мониторинг. AI инструментите за кодиране бързо свързват Clerk с разумни настройки по подразбиране; този списък улавя точките, които те оставят настрана.
За фон относно това защо неправилните конфигурации на auth слоя са слаба точка на AI инструменти, вижте Защо AI инструментите за кодиране оставят пропуски в сигурността. За паралелния контролен списък на Auth0, вижте Контролен списък за сигурност на Auth0.
Ключове на средата и allowlist за origin
Clerk издава два различни ключа за проект. Смесването или изтичането им е първият режим на отказ.
- Използвайте публикуемия ключ (
pk_live_*в продукция,pk_test_*в dev) в браузъра; използвайте секретния ключ (sk_live_*/sk_test_*) само на сървъра. Публикуемият ключ е безопасен вNEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; секретният ключ никога не трябва да носи публичен env префикс и никога не трябва да се появява в клиентски компонент. - Проверете, че production приложението използва
pk_live_*, а неpk_test_*. Test инстанциите позволяват непроверени имейл адреси и деактивиран MFA — изпращането на test mode в продукция е заобикаляне на автентикацията. - Конфигурирайте разрешените origin-и в Clerk Dashboard. Settings → Domains → Allowed origins трябва да изброява вашия production домейн точно. Празни или wildcard списъци с origin позволяват на нападателите да създадат rogue Clerk frontends, които комуникират с вашия backend.
- Ротирайте секретния ключ при всяко напускане или подозрение за изтичане. Dashboard → API Keys → Reset. Старият ключ е анулиран; преразгърнете сървърния код с новата стойност преди ротация.
Конфигурация на сесия
Срокът на сесията и idle timeouts са разликата между открадната сесия като 10-минутен инцидент и 30-дневен.
- Задайте session inactivity timeout на 30 минути или по-малко за SaaS приложения, обработващи чувствителни данни. Dashboard → Sessions → Inactivity timeout. Приложенията на банков ред трябва да използват 5-10 минути; стандартни SaaS 30-60 минути; потребителски приложения 1-7 дни. По подразбиране е 7 дни.
- Активирайте отнемане на сесии при смяна на парола, смяна на имейл и MFA регистрация. Dashboard → Sessions → Revoke on. Това са инициирани от потребител събития за сигурност; съществуващите сесии на други устройства трябва да бъдат прекратени.
- Проверявайте сесиите на сървъра на всеки защитен route, не само при влизане. В Next.js:
const { userId } = await auth();в server компонент / API route чете JWT от cookie-то и го валидира. Никога не се доверявайте само на проверка на cookie. - Задайте
SameSite=Lax(по подразбиране) илиStrictна session cookie-то. Проверете в DevTools → Application → Cookies.SameSite=Noneе CSRF вектор — никога не го използвайте, освен ако изрично сте конфигурирали cross-domain auth setup.
Проверка на webhooks
Webhooks на Clerk се задействат при събития от жизнения цикъл на потребителя (created, updated, deleted, session.ended). Те са механизмът за синхронизация на вашата база данни — и фалшифициран webhook е database-write primitive.
- Проверявайте Svix подписа на всеки webhook. Webhooks на Clerk се подписват от Svix. Използвайте
new Webhook(secret).verify(body, headers). Отхвърлете с401, ако проверката се провали. - Съхранявайте webhook секрета в променлива на средата, никога в кода. Секретът се ротира при всяко регенериране в Dashboard — вашият deploy трябва да го чете от env, а не от константа.
- Идемпотентност на всеки handler. Webhook доставките могат да се повтарят. Използвайте заглавката
svix-idкато primary key в таблицаwebhook_events, за да дедупликирате. Обвийте промяната на състоянието и идемпотентното вмъкване в същата транзакция. - При
user.deleted, hard-delete или анонимизирайте PII в рамките на 24 часа. GDPR / CCPA го изискват. Одитирайте пътя за изтриване: кои таблици съдържат данните на този потребител? Използвайте FK ON DELETE CASCADE, където можете.
Организации и разрешения
Ако използвате Clerk Organizations, границата на org е вашата tenant изолация. Всяка сървърна заявка трябва да филтрира по нея.
- На всеки API route четете както
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.
- Тествайте cross-org изолация с два реални org акаунта. Създайте Org A, попълнете данни, влезте в Org B в друг браузър, опитайте се да прочетете данните на Org A чрез API. Отговорът трябва да бъде
403или404.
JWT темплейти и външни интеграции
JWT темплейтите изпращат Clerk идентичността в Supabase, Firebase и други downstream услуги. Неправилно конфигурирани темплейти споделят твърде много claims или излагат данни, които не сте искали.
- За всеки JWT темплейт изброете всеки claim и потвърдете, че е необходим. Dashboard → JWT Templates. Темплейт, който изпраща
emailиphoneв Supabase, излага PII на всеки, който чете JWT в браузъра. - Задайте кратък срок на JWT темплейтите, използвани за client-side downstream извиквания. 60 секунди за downstream API заявки е стандартът. По-дълготрайните JWT се крадат и преиграват.
- Проверявайте audience (
aud) claim от страна на получателя. Supabase, Firebase и т.н. трябва да проверят, чеaudсъответства на очаквания идентификатор на услуга. Без това, JWT, издаден за услуга A, може да се автентикира за услуга B.
Оперативен мониторинг
Auth е източникът на логове с най-висок сигнал, който имате. Гледайте го.
- Алармирайте при скокове на неуспешни влизания за IP / акаунт. 50× нормалната честота на неуспех е атака credential-stuffing. Clerk излъчва тези събития до webhooks; маршрутизирайте ги към вашия SIEM.
- Тримесечен преглед на отклонения в настройките на сесии и инстанции. Стойностите по подразбиране се променят с обновленията на Clerk; "стари конфигурации" тихомълком стават погрешни с времето. Сравнете JSON експорта от Dashboard с последното ви известно добро копие.
Следващи стъпки
Изпълнете FixVibe сканиране срещу production URL — проверката baas.clerk-auth0 маркира публикуеми ключове на Clerk, test ключове в продукция и bundled секретни ключове. За еквивалентния контролен списък на Auth0, вижте Контролен списък за сигурност на Auth0. За общ преглед на BaaS доставчиците, прочетете Скенер за неправилни конфигурации на BaaS.