безопасность 1 мин

Нокодер запустил SaaS и понял, что не знает, защищены ли данные пользователей

Разработчик без технического бэкграунда за месяц создал SaaS с помощью Claude, привлёк реальных пользователей — и только тогда осознал, что понятия не имеет, может ли один пользователь получить доступ к данным другого. Теперь вручную проверяет изоляцию данных, подменяя ID в запросах, и переосмысливает подход к безопасности.

История показывает слепую зону AI-ассистированной разработки: инструменты помогают быстро собрать MVP, но не учат фундаментальным принципам безопасности. Для тысяч нокод-основателей это тикающая бомба — пока не поздно.

Когда AI помог запустить продукт, но не объяснил, как его защитить

Основатель без технического бэкграунда за месяц собрал работающий SaaS с помощью Claude. Продукт привлёк первых реальных пользователей — и именно в этот момент всё пошло не так.

Вопрос, который разрушил иллюзию

Друг-разработчик задал простой вопрос: «А может ли пользователь А подменить ID в запросе и увидеть данные пользователя Б?» Ответа не было. Claude генерировал код, интерфейс выглядел правильно — но изоляция данных (tenant isolation) это не «ощущение от UI», а проверки маршрутов, политики базы данных и права доступа.

Что пошло не так

Автор признаётся: он собирал приложение фрагментами — авторизация, правила БД и серверные функции обсуждались с Claude в разных диалогах. Права доступа изобретались «по одному промпту за раз», без системного видения.

Теперь предзапусковой чек-лист: - Тестирование подмены ID на всех маршрутах двумя пользователями - Секреты не должны утекать во фронтенд-код - Сессии с истечением времени жизни - Административные роуты, недоступные обычным пользователям - Логи без приватных данных

Урок для нокод-основателей

Автор переосмысливает подход: раньше использовал Enter Pro, где авторизация, БД и логика находились в едином потоке сборки — это давало более цельное понимание правил доступа. Но даже «чистый билдер» не доказывает изоляцию данных автоматически.

Вопрос к комьюнити остаётся открытым: что проверять перед тем, как реальные пользователи начнут работать с клиентскими данными?

Ключевые выводы

  • AI-ассистенты генерируют работающий код, но не объясняют критические аспекты безопасности
  • Изоляция данных (tenant isolation) требует системного подхода, а не фрагментарных промптов
  • «Работающий интерфейс» ≠ безопасная архитектура — проверка прав доступа обязательна до прихода реальных пользователей
  • Распределённые диалоги с AI создают разрозненную архитектуру без единой модели безопасности
  • Переход от прототипа к продукту требует ручного аудита всех критических маршрутов
безопасностьнокодSaaStenant isolationAI-разработка

Автор: Елена Верещагина · Источник: reddit.com

Мнение редакции

Это классический кейс «работает, пока не сломается». Claude отлично пишет код под конкретную задачу, но не держит в голове архитектуру целиком — особенно когда ты сам не понимаешь, что спрашивать. Разработка в стиле «диалог за диалогом» создаёт Франкенштейна из разрозненных кусков, где авторизация живёт отдельно от БД, а права доступа — вообще где-то сбоку.

Реальная проблема не в инструментах, а в том, что нокод-культура продаёт миф «запустишь за выходные». Можешь. Но между «работает у меня» и «можно пускать чужих людей с их данными» — пропасть из security-рисков, которые AI не подсветит сам. Автор молодец, что спохватился до катастрофы. Большинство узнают о дырах постфактум — из багрепортов или хуже.

Инструменты из статьи

AI-ассистент Anthropic. Сильнейший в работе с кодом, длинными документами и...

Доступ из РФ →

Ещё по теме

Комментарии