// docs / baas security / clerk hardening

Чек-лист безпеки Clerk: 20 пунктів

Clerk обробляє автентифікацію, сесії та організації для вашого застосунку — це означає, що неправильно налаштована інтеграція Clerk — це обхід автентифікації, вектор фіксації сесії або шлях витоку організацій. Цей чек-лист — це 20-пунктний аудит за ключами, конфігурацією сесій, вебхуками, організаціями, JWT-шаблонами та поточним моніторингом. ШІ-інструменти кодування підключають Clerk швидко з розумними значеннями за замовчуванням; цей список ловить пункти, які вони залишають на столі.

Для розуміння, чому неправильні налаштування auth-шару є слабким місцем ШІ-інструментів, дивіться Чому ШІ-інструменти кодування залишають прогалини в безпеці. Для паралельного чек-листа щодо Auth0 дивіться Чек-лист безпеки Auth0.

Ключі оточення та allowlist 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 має точно перелічити ваш продакшен-домен. Порожні або wildcard-списки 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 із cookie та валідує його. Ніколи не довіряйте перевірці лише по cookie.
Встановіть SameSite=Lax (за замовчуванням) або Strict на cookie сесії. Перевірте в DevTools → Application → Cookies. SameSite=None — це CSRF-вектор — ніколи не використовуйте його, якщо ви явно не налаштували міждоменну auth-схему.

Перевірка вебхуків

Вебхуки Clerk спрацьовують на події життєвого циклу користувача (created, updated, deleted, session.ended). Це механізм синхронізації для вашої бази даних — і підроблений вебхук — це примітив запису в базу.

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

Організації та дозволи

Якщо ви використовуєте Clerk Organizations, межа організації — це ваша ізоляція орендарів. Кожен запит на стороні сервера має фільтрувати за нею.

На кожному 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 та інші сервіси нижче. Неправильно налаштовані шаблони занадто діляться claims або розкривають дані, які ви не мали на увазі.

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

Операційний моніторинг

Auth — це джерело логів із найвищим сигналом, яке у вас є. Слідкуйте за ним.

Сповіщайте про сплески невдалих входів на IP / на акаунт. Рівень відмов у 50× від нормального — це атака credential-stuffing. Clerk видає ці події у вебхуки; направляйте їх у свій SIEM.
Щоквартальний перегляд дрейфу налаштувань сесій та інстансу. Значення за замовчуванням змінюються разом із оновленнями Clerk; "старі конфігурації" мовчки стають неправильними з часом. Порівняйте Dashboard JSON-експорт із вашою останньою відомою хорошою копією.

Наступні кроки

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