Вайб-гайд · 13 июля 2026

Безопасность: секреты, BOLA, валидация, webhooks и чеклист

Безопасность, чеклист и ошибки

Секреты: ключи нельзя хранить во фронтенде

Если ключ попал в JS-код, который уехал в браузер — считай, ключ скомпрометирован. Lovable прямо пишет «не хранить секреты во frontend code» и направляет хранить их в Secrets/Edge Functions.

Базовые практики OWASP по управлению секретами: централизованное хранение, контроль доступа, ротация, аудит.

Практичный минимум для MVP:

  • Ключи — только в server-side (edge functions / backend / secret store).
  • Доступ к секретам — ограничить.
  • Логи не должны печатать секреты.

BOLA: главная дыра в «MVP с таблицами»

BOLA (Broken Object Level Authorization) — когда у тебя есть эндпоинт типа /items/{id}, и система проверяет «ты залогинен», но не проверяет, что этот объект принадлежит тебе. Тогда злоумышленник меняет id и получает чужие данные. OWASP ставит это на первое место.

Мини-правило: любой эндпоинт, который принимает object id, должен проверять право доступа на уровне объекта.

Валидация входных данных: «не впускай мусор»

OWASP формулирует цель input validation просто: впускать только корректно сформированные данные как можно раньше, чтобы не ломать систему и не открывать атаки.

Практика для MVP:

  • Валидация на входе (schema-валидация).
  • Whitelist-подход (разрешённые значения), где возможно.
  • Ограничение размера запросов (чтобы не сожрали ресурсы).

Webhooks: проверяй подпись

Если ты принимаешь webhook и не проверяешь подпись — любой может стучаться в твой endpoint как «GitHub/платёжка/что угодно». GitHub даёт официальную инструкцию по валидации и рекомендует X-Hub-Signature-256 (HMAC-SHA256).

Env vars: полезно, но делай правильно

В Vercel env vars — это key-value пары вне исходников, а изменения применяются только к новым деплоям (нужен redeploy). Есть режим «Sensitive environment variables» — значения становятся нечитаемыми после создания.

Галлюцинации модели

Модели могут генерировать уверенный текст/код, который выглядит правильно, но фактически неверен — это называется галлюцинация. Это один из главных барьеров надёжности LLM и требует верификации и ограничений.

Токены и стоимость

Токены — это «счётчик объёма», из которого растёт стоимость. Если ты гоняешь агента в бесконечных итерациях без чёткого «done», ты платишь за хаос.

Главные ошибки новичков

  • Просить «сделай всё сразу» — результат будет хаотичным.
  • Не проверять — ИИ может ошибаться, и без проверки ты этого не заметишь.
  • Не контролировать секреты — утёкший ключ = потенциальные деньги и безопасность.
  • Выкатить прототип в прод — и удивляться проблемам с качеством.

Чеклист перед публикацией

  • Секреты: нет ключей во фронтенде/репозитории
  • Авторизация объектов: все эндпоинты с :id проверяют владельца/права (BOLA закрыт)
  • Валидация: входные данные проверяются, есть лимиты на размер
  • Webhooks: подписи валидируются, есть защита от повторов (idempotency key)
  • Окружения: dev/preview/prod разделены; превью-деплой работает
  • Git-история: есть репозиторий, можно откатиться; для агентных правок есть чекпоинты
  • README: любой сможет запустить проект по инструкции
  • Логи/ошибки: нет утечек персональных данных и секретов