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

> Аутентификация и авторизация простыми словами: чем «кто ты» отличается от «что тебе можно» и почему данные в вайбкод-приложениях утекают через вторую.

Published: 2026-03-06 · Source: https://subxcat.com/ru/articles/authentication-vs-authorization · Author: SUBXCAT

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

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

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

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

Важно, что вторая проверка происходит у каждой двери, а не один раз на входе. Замок номера 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 проверяет авторизацию в приложениях, собранных с ИИ, и закрывает найденные дыры до того, как их найдут пользователи.