Нет авторизации: любой видит чужие данные

Самая неприятная находка в вайб-код проекте — это не баг, а дыра: пользователь меняет в адресе /orders/1052 на /orders/1051 и видит чужой заказ, телефон и адрес. Такую уязвимость называют IDOR, и она входит в число самых распространённых в веб-приложениях. ИИ делает её особенно часто, потому что проверку прав нужно продумать, а не просто написать.

Почему так происходит

• Защита только во фронтенде. Кнопка «Админка» скрыта для обычных пользователей, но адрес /api/admin/users отвечает всем.
• Доверие к данным из запроса. Сервер берёт userId из тела запроса или параметра, а не из сессии. Подставить чужой номер может любой.
• Нет фильтра по владельцу. Запрос select * from orders where id = $1 без условия на владельца.
• Открытые правила базы. Firebase в тестовом режиме разрешает читать и писать всем до указанной даты. Supabase с выключенным RLS открывает таблицу любому, у кого есть публичный ключ — а он в коде вашего сайта.
• Секретный ключ во фронтенде. Ключ, обходящий все правила, оказался в браузере.

Что проверить самому

1. Создайте два тестовых аккаунта. Под первым откройте свой заказ или профиль, скопируйте адрес, затем войдите вторым и откройте этот адрес.
2. В DevTools → Network посмотрите API-запросы. Попробуйте повторить запрос с другим номером записи.
3. Попробуйте открыть админские адреса, не входя в систему.
4. В Firebase откройте Rules. Опасный признак:

allow read, write: if true;

или условие только по дате request.time < timestamp.date(...).

5. В Supabase проверьте, что RLS включён на всех таблицах с данными пользователей.
6. Поищите в коде сервера места, где пользователь берётся из req.body или req.query.

Если хотя бы одна проверка «пробила» — не откладывайте, а заодно проверьте, нет ли секретных ключей в коде страницы.

Когда звать разработчика. Если дыра найдена, первое — временно закрыть доступ: отключить эндпоинт, включить RLS или поставить строгие правила Firebase, даже если часть функций перестанет работать. Дальше нужен разработчик, который проверит все точки доступа, а не только найденную: такие ошибки обычно системные, и одна найденная означает, что тот же подход повторён в других местах проекта.

Как чиним мы

Проводим аудит всех точек доступа к данным: эндпоинты, прямые запросы к базе из фронтенда, правила Firebase или RLS в Supabase. Составляем матрицу ролей и прав, вводим проверку владельца в каждом запросе, переносим определение пользователя в сессию или проверенный токен, закрываем админские маршруты. Добавляем автотесты «чужой пользователь получает 403». По логам помогаем оценить, были ли обращения к чужим записям. Подробнее — на странице «Аптечка вайб-кода».

Сколько стоит

Диагностика — 50 000 ₸, аудит безопасности и исправление доступа — 60 000 ₸, итого от 110 000 ₸ для небольшого проекта. Для кабинетов с ролями и большим количеством таблиц действует коэффициент размера. Рассчитайте в калькуляторе.