Одна из самых важных идей в безопасности ПО звучит так: доказать, кто такой пользователь, — не то же самое, что решить, что этому пользователю разрешено делать.
Это различие кажется простым, но многие серьёзные уязвимости появляются именно потому, что система правильно делает authentication, а потом предполагает, что authorization тоже автоматически в порядке.
Это не так.
Базовая разница
- Authentication отвечает на вопрос: Кто ты?
- Authorization отвечает на вопрос: Что тебе разрешено делать?
Если пользователь успешно вошёл в систему, authentication сработал. Но это не означает, что пользователь должен видеть все аккаунты, редактировать любые ресурсы, скачивать любые файлы или вызывать любые admin endpoints.
Простой пример из реальной жизни
Представьте mobile banking app.
Вы входите через email, пароль и OTP. Это authentication.
Затем вы пытаетесь открыть endpoint с деталями счёта, подставив account ID другого клиента. Остановит ли вас система или нет — это уже вопрос authorization.
Если backend проверяет только “Пользователь вошёл?” и забывает проверить “Этот вошедший пользователь действительно владеет этим счётом?”, то в системе есть реальная уязвимость.
Вот почему многие опасные баги связаны не со сломанным login screen, а с отсутствием permission checks после логина.
Почему это так важно для websites и mobile apps
- Даже вошедшие пользователи представляют угрозу для чужих данных. Authentication не делает каждое действие безопасным.
- API легко прощупывать. Атакующие могут менять ID, параметры и запросы напрямую.
- Frontend-ограничений недостаточно. Спрятанная кнопка в UI не защищает backend endpoint.
- Mobile app — не доверенный клиент. Backend должен сам enforce-ить permissions.
В этом и скрытая опасность: команды часто хорошо защищают login flow, но слабо защищают действия после входа.
Типичные примеры ошибок authorization
- пользователь может читать чужой профиль, меняя ID в URL
- клиент может открыть чужой invoice или document
- обычный пользователь может вызвать admin-only API route
- mobile app визуально скрывает admin feature, но endpoint всё равно работает при прямом вызове
- пользователь может update или delete ресурс, которым не владеет
Такие проблемы часто называют access control failures, и это одни из самых опасных багов в реальных продуктах.
Почему разработчики случайно допускают эту ошибку
- они считают, что “logged in” уже достаточно
- они доверяют frontend-у ограничивать действия
- они проверяют role в некоторых endpoints, но забывают про ownership конкретного объекта
- они быстро ship-ят feature и добавляют permission checks непоследовательно
- они тестируют happy paths чаще, чем hostile ones
Иными словами, баг часто возникает не из-за злого умысла, а из-за неполной модели мышления.
Как об этом думать правильно
Для каждого чувствительного действия backend должен задавать такие вопросы:
- Пользователь authenticated?
- У этого пользователя есть нужная role?
- Принадлежит ли этому пользователю именно этот resource?
- Разрешено ли это действие в текущем state?
- Должны ли эти данные вообще быть видимы этому пользователю?
Вот как выглядит настоящий authorization. Это не один большой yes/no switch. Это набор проверок, привязанных к действию и ресурсу.
Скрытый урок: безопасность часто живёт в скучных проверках
Люди часто представляют app security как encryption, tokens или advanced attack defense. Это важно. Но многие реальные breaches происходят по более скучной причине: отсутствует permission check на обычном endpoint.
Поэтому сильные команды воспринимают authorization как product rule, а не как техническую мелочь. Вопрос не только в том, “Может ли пользователь войти?” Вопрос ещё и в том, “К чему именно этот пользователь должен иметь доступ после входа?”
Опасное заблуждение
Распространённая мысль: “UI не показывает эту функцию, значит пользователь не может к ней получить доступ”.
Это опасное мышление. Атакующим не нужны ваши кнопки. Они могут вызывать API напрямую, изменять запросы и тестировать endpoints без обычного интерфейса.
Итог
Authentication подтверждает личность. Authorization управляет полномочиями. Безопасному продукту нужны оба слоя. Если ваш website или mobile app проверяет только, кто пользователь, но не что именно он может просматривать или изменять, у вас может быть серьёзная уязвимость, скрытая за идеально работающим login flow.