Чек-лист безпеки SaaS перед запуском: 40 перевірок, які ми виконуємо першими (2026)

Чек-лист безпеки SaaS перед запуском: 40 перевірок, які ми виконуємо першими (2026)

Чек-лист безпеки SaaS перед запуском цінніший за купу значків відповідності стандартам, яких у вас ще немає. Ось незручна правда: більшість чек-листів для запуску кажуть вам, що саме потрібно захищати, але ніколи не показують, як це зробити. Цей містить готовий код. Ми будуємо на базі Next.js та Supabase, бачили, як один відсутній фільтр tenant_id дозволив тестовому акаунту читати дані іншого клієнта, а звіт IBM про вартість витоку даних за 2024 рік вказує середній світовий збиток у розмірі $4,88 млн. Вам не потрібен SOC 2, щоб запуститися. Вам потрібна наведена нижче базова лінія безпеки на рівні додатка, згрупована, готова до виконання та співвіднесена зі стандартами OWASP та NIST.

Ключові висновки

• Вам не потрібен SOC 2 або пентест для запуску. Вам потрібна наведена нижче базова лінія безпеки на рівні додатка.
• Найнебезпечніший баг при запуску — витік даних між орендарями через відсутність перевірки tenant_id.
• Ніколи не створюйте власну систему автентифікації з нуля. Використовуйте Auth.js, Clerk або Supabase Auth.
• Перевіряйте префікси NEXT_PUBLIC_ перед деплоєм. Це найшвидший спосіб розкрити секрет.

Ця базова лінія відповідає OWASP ASVS 5.0 та NIST Secure Software Development Framework (SSDF) — двом довідникам, яким Google довіряє найбільше в цій темі, і, що примітно, двом, на які жоден із топ-рейтингових гайдів навіть не посилається.

Ваш чек-лист безпеки перед запуском (коротка версія)

Це мінімальні вимоги безпеки перед релізом, згруповані в шість категорій. Сорок пунктів. Виконуйте їх по порядку, передайте розділи з кодом вашому розробнику і ставтеся до всього, що позначено як P0 у таблиці пріоритетів нижче, як до блокувальників запуску.

Секрети та конфігурація

1. Файл .env додано в .gitignore з самого першого коміту і ніколи не комітився.
2. Кожен префікс NEXT_PUBLIC_ та VITE_ перевірено; жодні секрети не потрапляють у браузер.
3. Серверні секрети зберігаються в менеджері (змінні середовища платформи, AWS Secrets Manager, Vault), а не в репозиторії.
4. Будь-який ключ, який коли-небудь потрапляв в історію git, ротовано перед запуском.
5. Жодні секрети не з’являються в логах, пейлоадах помилок або клієнтському бандлі.
6. Ви перевірили зібраний бандл на наявність активних ключів (grep -r "sk_live" .next/).

Автентифікація та доступ

1. Автентифікація побудована на бібліотеці (Auth.js, Clerk або Supabase Auth), а не написана вручну.
2. Багатофакторна автентифікація (MFA) доступна для акаунтів.
3. Куки сесій мають прапорці Secure, HttpOnly та SameSite.
4. JWT або токени сесій не зберігаються в localStorage.
5. RBAC та ролі з мінімальними привілеями забезпечуються на стороні сервера, а не просто приховані в UI.
6. Паролі хешуються за допомогою Argon2 або bcrypt (лише якщо ви самостійно керуєте автентифікацією).
7. Потоки скидання пароля та підтвердження електронної пошти перевірені на стійкість до зложивань.

Дані та орендарство

1. Кожен запит містить фільтр tenant_id.
2. Область дії орендаря забезпечується на рівні ORM або репозиторію, а не пам’ятається для кожного запиту окремо.
3. Безпека на рівні рядків (Row-level security) увімкнена, а її можливі збої зрозумілі.
4. Кожна точка доступу з ID об’єкта виконує перевірку права власності (це усуває IDOR).
5. tenant_id включено в ключі кешу та шляхи до сховища об’єктів.
6. Дані шифруються під час зберігання та передачі.
7. Підписи платежів та вебхуків (Stripe тощо) перевіряються на стороні сервера.

Залежності та ланцюжок постачання

1. npm audit або pnpm audit не містить проблем високого та критичного рівня (або вони явно класифіковані).
2. Увімкнено Dependabot або Renovate.
3. Snyk або Socket виконують глибшу перевірку SCA, а також перевірку на шкідливе ПЗ та ліцензії.
4. Lockfile закомічено.
5. У критичному шляху немає покинутих або непідтримуваних пакетів.
6. Образы контейнерів скануються, якщо ви використовуєте Docker.

Мережа та транспорт

1. HTTPS примусово увімкнено всюди, з попереднім завантаженням HSTS.
2. Встановлено Content-Security-Policy (спочатку в режимі звітування, потім примусово).
3. Встановлено X-Content-Type-Options: nosniff та X-Frame-Options/frame-ancestors.
4. Встановлено Referrer-Policy та Permissions-Policy.
5. CORS використовує список дозволених джерел, ніколи * разом із обліковими даними.
6. Обмеження частоти запитів (rate limiting) захищає автентифікацію та ресурсомісткі точки доступу.
7. Кожна точка доступу валідує вхідні дані за схемою (Zod або подібною).

Моніторинг та реагування

1. Централізовані журнали аудиту фіксують, хто, до чого отримав доступ і коли.
2. Обробка помилок ніколи не розкриває стек-трейси користувачам.
3. Сповіщення спрацьовують при аномаліях автентифікації (сплески невдалих входів, неможливі переміщення).
4. Автоматичне резервне копіювання працює, і ви протестували відновлення.
5. Існує контактна особа для реагування на інциденти та односторінковий план дій (runbook).
6. Працює моніторинг аптайму та помилок (Sentry або аналог).
7. Ви знаєте тригер для залучення пентесту.

Пріоритет виправлень

Не кожен пункт блокує запуск. Ця таблиця тріажу сортує базову лінію за ступенем шкоди у разі пропуску, щоб засновник знав, що є неприпустимим. P0 = виправити перед запуском, P1 = виправити протягом першого тижня, P2 = виправити протягом кварталу.

Секрети та конфігурація: Чи потрапляють якісь ключі у ваш клієнтський бандл?

Гігієна секретів при запуску означає, що жодні облікові дані ніколи не досягають браузера. Префікс NEXT_PUBLIC_ у Next.js (та VITE_ у Vite) надсилає значення кожному відвідувачу, тому один неправильний префікс розкриває ключ. Тримайте .env поза git, розміщуйте серверні секрети в менеджері та перевіряйте результати збірки перед деплоєм.

Ось найпоширеніша пастка, яку ми бачимо: NEXT_PUBLIC_ не означає «публічна інформація». Це означає «я буквально відправляю це в браузер кожного відвідувача». Додайте такий префікс до секретного ключа Stripe або ключа сервісної ролі, і він стане доступним у бандлі для будь-кого, хто відкриє DevTools.

# .env.local (the mistake)
NEXT_PUBLIC_STRIPE_SECRET=sk_live_51H...   # BAD: ships to every browser
STRIPE_SECRET_KEY=sk_live_51H...           # OK: server-only

# Public (safe to expose) vs server-only
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJ...       # anon key is meant to be public
SUPABASE_SERVICE_ROLE_KEY=eyJ...           # never NEXT_PUBLIC_ this

# Catch a leaked key before you deploy
grep -r "sk_live" .next/    # any hit means a secret is in your client bundle

Решта базових вимог до секретів нудна, але обов’язкова: .env у .gitignore з першого коміту, серверні секрети в менеджері, а не в репозиторії, та ротація будь-якого ключа, який коли-небудь потрапляв в історію git (видалення коміту не скасовує витік). Витік токена деплою — це саме те, з чого починаються такі інциденти, як інцидент Vercel, тому ставтеся до кожного токена так, ніби він уже є в чиємусь списку спостереження.

Автентифікація та доступ: Чи варто будувати автентифікацію самому чи використовувати бібліотеку?

Чи варто будувати автентифікацію самому чи використовувати бібліотеку? Майже завжди використовуйте бібліотеку. Auth.js, Clerk та Supabase Auth вже вирішили роками накопичені крайні випадки, які ви інакше будете заново відкривати у продакшені: фіксація сесії, анулювання токенів, зложивання потоками скидання пароля. Створення власного рішення виправдане лише за наявності інженера з безпеки та причини, чому жоден провайдер не підходить, що трапляється рідко.

Створення власної автентифікації — найдорожчий спосіб заощадити $25 на місяць. Ось як чесні варіанти порівнюються між собою.

Дві пастки гублять команди, які обирають бібліотеку, але пропускають налаштування. По-перше, анулювання JWT справді складне, тому вкрадений токен залишається дійсним до закінчення терміну дії; тримайте термін життя токенів коротким і надавайте перевагу серверним сесіям для всього чутливого. По-друге, токени в localStorage можна вкрасти будь-яким XSS-пейлоадом, тому зберігайте сесії в куках httpOnly з прапорцями Secure та SameSite. Забезпечуйте RBAC на сервері, а не шляхом приховування кнопок в UI.

Якщо ваш SaaS має функцію AI або LLM, ставтеся до введення моделі як до ненадійної межі автентифікації також. Дивіться наш гайд щодо запобігання ін'єкціям промптів, тому що зламаний асистент з доступом до інструментів — це проблема контролю доступу, замаскована під вікно чату.

Дані та орендарство: Як запобігти читанню даних одного орендаря іншим?

Ізоляція орендарів означає, що кожен запит, ключ кешу та шлях до сховища обмежені поточним орендарем. Відсутній фільтр tenant_id дозволяє одному клієнту читати дані іншого — це найнебезпечніший баг при запуску. Безпека на рівні рядків допомагає, але це ремінь безпеки, а не силове поле, тому додавайте перевірки права власності на кожну точку доступу з ID об’єкта.

Це розділ, який жоден конкурент не висвітлює через код, і саме через нього витоки між орендарями потрапляють у продакшен. Виправлення починається з того, щоб ніколи не довіряти ID сам по собі. Обмежуйте кожне читання тенантом викликача та забезпечуйте це на рівні даних, щоб нікому не потрібно було пам’ятати про це для кожного запиту.

// BAD: no tenant scope. Any valid id returns any tenant's row.
const order = await db.order.findFirst({ where: { id } });

// GOOD: scoped to the caller's tenant on every read.
const order = await db.order.findFirst({
  where: { id, tenantId: session.tenantId },
});

Пов’язаний збій — це IDOR (небезпечне пряме посилання на об’єкт), який OWASP API Security Top 10 класифікує як API1: Broken Object Level Authorization. Тестовий акаунт збільшує ID в URL і читає запис, якого ніколи не повинен бачити. На Web Security Academy від PortSwigger є повний огляд того, як зловмисники знаходять такі вразливості. Виправлення — це одна перевірка права власності.

// GET /api/invoices/1234, a test account increments the id
// and reads another tenant's invoice. Classic BOLA.
const invoice = await db.invoice.findUnique({ where: { id } });

// Fix: verify ownership before you return anything.
if (invoice.tenantId !== session.tenantId) {
  return res.status(403).json({ error: "Forbidden" });
}

Ось формулювання, яке допоможе вам залишатися чесними: кожен IDOR є збоєм ізоляції орендарів, але не кожен збій ізоляції орендарів є IDOR. Row-level security у Postgres перехоплює багато з них на рівні бази даних, але має режимы тихих збоїв, про які варто знати, перш ніж покладатися на них.

-- Postgres RLS: a seatbelt, not a force field.
alter table orders enable row level security;

create policy tenant_isolation on orders
  using (tenant_id = current_setting('app.tenant_id')::uuid);
-- Silent-failure trap: forget to SET app.tenant_id on a pooled
-- connection and the policy reads the PREVIOUS request's tenant.

Забруднення пулу з’єднань, витоки асинхронного контексту та отруєння спільного кешу тихо обходять RLS, тому OWASP Multi-Tenant Security Cheat Sheet радить додавати префікс орендаря до ключів кешу та шляхів до сховища. Розділ контролю доступу в OWASP ASVS 5.0 та документація Supabase RLS — це два джерела, які варто прочитати повністю в цьому контексті.

Залежності та ланцюжок постачання: Що ховається у ваших node_modules?

Ваш додаток настільки ж безпечний, наскільки безпечна його найслабша транзитивна залежність. Запускайте npm audit або pnpm audit у CI та блокуйте збірку при виявленні проблем високого або критичного рівня ще до запуску. Додайте Dependabot або Renovate для автоматичних оновлень та Snyk або Socket для глибшої перевірки на шкідливе ПЗ та ліцензії.

Пастка полягає в тому, щоб запустити аудит один раз вручну, побачити зелений статус і більше ніколи його не запускати. Інтегруйте його в CI, щоб новий CVE в пакеті, якого ви не торкалися, все одно блокував злиття.

# .github/workflows/ci.yml: block the merge on high/critical
- name: Audit dependencies
  run: npm audit --audit-level=high    # non-zero exit fails the job

Документація npm audit охоплює рівні серйозності та прапорець --production, якщо ви хочете ігнорувати проблеми, специфічні лише для розробки. Автоматизоване сканування — це мінімум; для глибшого статичного аналізу, який виявляє запахи коду та шляхи ін'єкцій, що пропускають сканери залежностей, дивіться наш огляд SonarQube. Комітьте ваш lockfile, видаляйте пакети, які не оновлювалися роками, та скануйте образ контейнера, якщо ви деплоїте Docker.

Мережа та транспорт: Які заголовки безпеки дійсно потрібні SaaS?

Які заголовки безпеки потрібні SaaS? HTTPS плюс HSTS та короткий набір заголовків закривають найлегші для експлуатації прогалини. Додайте Content-Security-Policy, список дозволених джерел для CORS замість wildcard та обмеження частоти запитів на точках автентифікації та ресурсомістких ендпоінтах. Валідуйте кожне введення за схемою, такою як Zod, щоб погані пейлоади ніколи не досягали вашої логіки.

Вам не потрібен кожен винайдений коли-небудь заголовок. Вам потрібен цей короткий список, а довідник MDN щодо заголовків безпеки детально пояснює кожен із них.

Встановіть заголовки один раз на edge та додайте обмежувач частоти запитів, щоб скрипт не міг перебирати паролі до вашого маршруту входу всю ніч.

// next.config.js: security headers on every response
const securityHeaders = [
  { key: "Strict-Transport-Security", value: "max-age=63072000; includeSubDomains; preload" },
  { key: "X-Content-Type-Options", value: "nosniff" },
  { key: "X-Frame-Options", value: "DENY" },
  { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
];
// Rate-limit auth routes (Upstash example)
const { success } = await ratelimit.limit(ip);
if (!success) return new Response("Too many requests", { status: 429 });

Почніть свій CSP у режимі report-only, щоб не зламати власний додаток, спостерігайте за звітами про порушення кілька днів, а потім увімкніть примусове виконання. Тримайте CORS у межах іменованого списку дозволених джерел і ніколи не поєднуйте * з обліковими даними.

Моніторинг та реагування: Як ви дізнаєтеся, що вас зламали?

Ви не можете реагувати на те, чого не бачите. Перед запуском налаштуйте централізовані журнали аудиту, сповіщення про аномалії автентифікації, такі як сплески невдалих входів, автоматичне резервне копіювання з протестованим відновленням та односторінковий план дій при інцидентах. Непротестований бекап — це надія, а не бекап, і час писати план дій зараз, а не під час інциденту.

Дані IBM показують, що середній час виявлення та стримування витоку становить 258 днів, і ви не зможете скоротити це число, якщо ваші логи не фіксують, хто до чого мав доступ. Централізуйте їх, налаштуйте сповіщення про важливі аномалії (сплески невдалих входів, входи з неможливих локацій, раптове збільшення обсягу експорту) та переконайтеся, що ваш обробник помилок повертає чисте повідомлення замість стек-трейсу, який розкриває вашу внутрішню структуру.

Сучасне виявлення витоків покладається на моніторинг аномалій, а не на статичні правила; більше про те, як це працює на практиці, у нашій статті про те, як AI запобігає витокам даних. Щодо框架, то NIST SSDF (SP 800-218) викладає практики реагування та моніторингу зрозумілою мовою. Протестуйте відновлення перед запуском, а не після того, як ваша база даних зникне.

Що ми фактично знаходимо, коли перевіряємо власні запуски

Коли наша команда проводить перевірку безпеки перед запуском для власної збірки або збірки клієнта, дві помилки зустрічаються частіше за інші. По-перше: секрет, який потрапляє в браузер через префікс NEXT_PUBLIC_, зазвичай це ключ стороннього API, який хтось позначив таким префіксом, щоб зробити клієнтський запит працюючим. По-друге: принаймні одна точка доступу без області дії tenant_id або перевірки права власності.

Пропуск області дії орендаря лякає тим, що додаток виглядає нормально. Кожна сторінка завантажується. Баг проявляється лише тоді, коли хтось змінює ID в URL. Під час одного огляду GET /api/orders/:id повертав будь-яке замовлення будь-якому залогіненому користувачеві; тестовий акаунт читав замовлення іншого орендаря, просто збільшуючи номер. Виправлення зайняло два рядки: порівняти order.tenantId з session.tenantId перед поверненням.

Ми не будемо називати вам вигаданий відсоток виявлених проблем. Чесно та відтворювано можна сказати наступне: витік через NEXT_PUBLIC_ та відсутня область дії орендаря — це дві речі, які ми знаходимо майже в кожному огляді першого проходження, і обидві дешеві у виправленні, якщо ви знаєте, де шукати. Саме тому чек-лист виносить їх на перший план як P0.

Якщо ви хочете, щоб команда провела цю перевірку за вас перед днем запуску, це саме та робота, яку ми виконуємо. Отримати перевірку безпеки перед запуском →

Про автора

Мерт Батур Гюрбуз є співзасновником Techsy.io, де команда розробляє AI-агентів, системи автоматизації та голосові/SDR-пайплайни для B2B-клієнтів. Він навчається в Бірмінгемському університеті та пише про стек інструментів LLM, який команда Techsy фактично використовує у продакшені. Підключайтеся на LinkedIn.

Часто задавані питання

Що має бути в чек-листі безпеки SaaS перед запуском?

Шість категорій: секрети та конфігурація (тримайте ключі поза клієнтським бандлом), автентифікація та доступ (використовуйте бібліотеку, додайте MFA), дані та орендарство (область дії tenant_id плюс перевірки права власності), залежності (npm audit у CI), мережа та транспорт (HTTPS, HSTS, CSP, обмеження частоти запитів) та моніторинг і реагування (журнали аудиту, протестовані бекапи, план дій).

Чи достатньо безпечний мій SaaS для запуску?

Ви готові, коли завершено базову лінію P0: секрети поза клієнтським бандлом, ізоляція орендарів у кожному запиті, автентифікація на бібліотеці, HTTPS із заголовками безпеки та чисте сканування залежностей. Досконалість не є критерієм. Запущений, моніторингований додаток із покритою базовою лінією кращий за «ідеальний», який ніколи не запускається.

Чи потрібен мені пентест перед запуском SaaS?

Не для легального запуску. Пріоритетизуйте його, якщо ви обробляєте платежі або персональні дані (PII), цілитеся на корпоративних покупців, або якщо цього вимагає аудитор чи інвестор. На етапі MVP витрачайте ці зусилля спочатку на базову лінію рівня додатка та OWASP Top 10. Пентест знаходить більше, коли очевидні прогалини IDOR та заголовків уже закриті.

Чи потрібен мені SOC 2 для запуску SaaS?

Ні. Жоден клієнт не очікує SOC 2 від стартапу, який запустився минулого тижня. Це ключ для корпоративних продажів, а не бар’єр для запуску, і це займає місяці. Запускайтеся з базовою лінією рівня додатка, а потім починайте процес SOC 2, коли реальна корпоративна угода потребує цього, а не раніше.

Чи варто будувати власну автентифікацію чи використовувати бібліотеку, таку як Auth.js, Clerk або Supabase Auth?

Майже завжди використовуйте бібліотеку. Auth.js, Clerk та Supabase Auth вже впоралися з крайніми випадками сесій, токенів та потоків скидання пароля, які спричиняють більшість багів у самописній автентифікації. Створення власного рішення виправдане лише якщо у вас є інженер з безпеки та жорстка вимога, якій не відповідає жоден провайдер, що трапляється вкрай рідко.

Як тримати секрети поза моїм клієнтським бандлом?

Перевіряйте кожен префікс NEXT_PUBLIC_ та VITE_, оскільки все з таким префіксом потрапляє в браузер. Тримайте .env поза git з першого коміту, зберігайте серверні секрети в менеджері та перевіряйте зібраний бандл (grep -r "sk_live" .next/) перед деплоєм, щоб виявити витік ключа.

Як ізолювати дані орендарів у багатокористувацькому SaaS?

Додайте фільтр tenant_id до кожного запиту та забезпечте його на рівні ORM або репозиторію, щоб це відбувалося автоматично. Увімкніть безпеку на рівні рядків та вивчіть її можливі збої (забруднення пулу, асинхронні витоки). Додайте перевірку права власності до кожної точки доступу з ID об’єкта, щоб закрити IDOR, та обмежте ключі кешу та шляхи до сховища за орендарем.

Які заголовки безпеки потрібні SaaS перед запуском?

Мінімум: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options або frame-ancestors, Referrer-Policy та Permissions-Policy. Почніть свій CSP у режимі report-only, перегляньте порушення, а потім увімкніть примусове виконання. Документація MDN щодо заголовків безпеки містить рекомендовані значення для кожного, а таблиця заголовків вище підсумовує, що кожен із них зупиняє.

Чи достатньо автоматизованого сканування, такого як npm audit або Snyk?

Необхідно, але недостатньо. Такі інструменти, як npm audit, Snyk та Socket, виявляють відомі CVE та шкідливі пакети, але вони не можуть знайти вади бізнес-логіки та контролю доступу, такі як IDOR або відсутня область дії орендаря. Для цього потрібна людина, тестовий акаунт та явна перевірка права власності. Використовуйте обидва підходи: сканер та ручну перевірку.

Підсумок: Чек-лист безпеки SaaS, який ви дійсно можете запустити

Вам не потрібно бути ідеальним, щоб запуститися. Вам потрібна базова лінія. Спочатку закрийте пункти P0: секрети поза бандлом, ізоляція орендарів у кожному запиті, перевірка права власності на кожній точці доступу з об’єктом, автентифікація на бібліотеці та HTTPS із заголовками. Якщо ви виправите одну річ перед запуском у п’ятницю, нехай це буде ізоляція орендарів, тому що саме цей баг призводить до витоку даних клієнта без попередження.

Все тут можна виконати вже сьогодні, і нічого з цього не вимагає бюджету на комплаєнс. Пройдіть через 40 перевірок, передайте розділи з кодом вашому розробнику та запускайтеся. Хочете другого погляду перед тим, як вийти в онлайн? Отримайте безкоштовну консультацію, і ми пройдемо список разом із вами.