Аутентификация и авторизация: кто ты и что тебе можно

Аутентификация — это проверка того, кто ты: приложение убеждается, что человек действительно владелец аккаунта. Авторизация — это проверка того, что тебе можно: может ли этот человек прочитать этот заказ, изменить этот профиль, открыть эту админку.

Слова похожи, и их постоянно путают. Но аутентификация и авторизация — две разные проверки, и ломаются они по-разному. Особенно в приложениях, собранных с ИИ.

Аутентификация и авторизация на примере гостиницы

На стойке регистрации у тебя спрашивают паспорт. Это аутентификация: гостиница убеждается, что ты — тот, на кого забронирован номер. Потом тебе выдают карту-ключ. Она открывает дверь твоего номера, лифт и спортзал, но не открывает чужие номера и служебные помещения. Это авторизация.

Важно, что вторая проверка происходит у каждой двери, а не один раз на входе. Замок номера 512 не интересуется, что ты показал паспорт на ресепшене. Он проверяет, есть ли у твоей карты право на номер 512.

В приложении всё так же:

• Аутентификация — вход по паролю, коду из письма, через Google. На выходе — сессия: приложение знает, что запросы шлёт пользователь с идентификатором user_17.
• Авторизация — проверка при каждом запросе: может ли user_17 получить счёт номер 9381? Удалить этот комментарий? Поменять себе тариф?

Когда сервер отвечает ошибкой, разница тоже видна: 401 Unauthorized обычно означает «я не знаю, кто ты», а 403 Forbidden — «я знаю, кто ты, и тебе сюда нельзя».

Почему утечки чаще случаются в авторизации

Аутентификацию сегодня почти никто не пишет сам. Её берут готовой: Supabase Auth, Firebase, Clerk, Auth0 и им подобные. Эти сервисы годами отлаживали вход, сброс пароля и хранение сессий, и ИИ-ассистент подключает их довольно аккуратно. Вход работает, и на этом многие успокаиваются.

Авторизация готовой не бывает. Правила «кто что может» у каждого продукта свои: кто видит заказ, может ли менеджер править чужие сделки, что доступно на бесплатном тарифе. Их приходится описывать самому, и именно здесь ИИ чаще всего срезает углы.

Типичная картина в вайбкод-приложении:

• Проверка только в интерфейсе. Кнопки «Открыть чужой счёт» нет, но запрос на /api/invoices/9381 вернёт любой счёт любому вошедшему пользователю. Сервер проверил, что ты вошёл, но не проверил, что счёт твой.
• Роль хранится у пользователя. Признак isAdmin лежит в профиле, который пользователь может редактировать сам, или вообще приходит из браузера.
• Доступ по идентификатору. Номера записей идут по порядку, и, перебирая их, можно выкачать всю базу. Это называется IDOR — небезопасная прямая ссылка на объект.
• Открытые таблицы. В Supabase таблица без правил доступа отдаёт все строки любому, у кого есть публичный ключ, а он есть у каждого посетителя сайта.

Во всех этих случаях вход работает идеально. Злоумышленнику даже не нужно ничего взламывать: он честно регистрируется и честно просит чужие данные.

Как сделать авторизацию правильно

1. Проверяй на сервере, при каждом запросе. Интерфейс может прятать кнопки ради удобства, но решение «можно или нельзя» принимает бэкенд или правила доступа в базе.
2. Бери владельца из сессии, а не из запроса. Сервер сам знает, кто вошёл. Если user_id приходит в теле запроса и сервер ему верит, любой подставит чужой.
3. Ищи записи вместе с владельцем. Не «найди счёт 9381», а «найди счёт 9381, принадлежащий этому пользователю». Чужой счёт тогда просто не найдётся.
4. Храни роли там, куда пользователь не дотягивается. Отдельная таблица или поле, которое меняется только сервером.
5. Запрещай по умолчанию. Новая таблица или новый эндпоинт закрыты, пока ты явно не решил, кому их открыть.

Как проверить своё приложение

Заведи два обычных аккаунта. Из-под первого создай что-нибудь личное: заказ, документ, сообщение. Скопируй его идентификатор из адресной строки или вкладки Network. Войди вторым и запроси эту запись напрямую — прочитать, изменить, удалить. Потом попробуй зайти на адреса админки обычным пользователем.

Если хоть один запрос прошёл, проблема не во входе, а в авторизации, и чинить нужно её.

Коротко

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

SUBXCAT проверяет авторизацию в приложениях, собранных с ИИ, и закрывает найденные дыры до того, как их найдут пользователи.