"Безопасность API, это не про шифрование и сертификаты, а про то, как система решает, кому можно, а кому нельзя. Самые частые ошибки, это не баги в коде, а неверные допущения о том, как работает авторизация в распределённой системе. Мы часто думаем о проверке токена, но забываем, что происходит после неё."
Почему авторизация в API, это отдельная вселенная
Веб-приложение и API, это разные миры с точки зрения безопасности. В классическом вебе есть сессия, браузер, куки, Same Origin Policy. Запрос к API, это голый HTTP-запрос, часто из недоверенной среды: мобильное приложение, другой сервис, скрипт. Здесь нет встроенных механизмов браузера, которые хоть как-то ограничивают межсайтовые атаки. Каждый вызов должен сам доказывать свои права, и система должна этот вызов валидировать с нуля. Основная ошибка — переносить ментальные модели и подходы из веб-разработки в API без адаптации.
Типичные ошибки авторизации, которые встречаются постоянно
Эти проблемы не являются экзотическими уязвимостями нулевого дня. Это системные просчёты в архитектуре и реализации, которые возникают снова и снова.
1. Недостаточная проверка scope или роли токена
Система проверяет, что токен валиден и принадлежит пользователю X, но не проверяет, разрешено ли этому токену выполнять конкретное действие. Например, токен для чтения профиля используется в запросе на удаление этого профиля. Механизм OAuth 2.0 предоставляет scope, JWT может содержать roles или permissions, но часто эта информация игнорируется на уровне бизнес-логики. Проверка сводится к «токен есть? — ок», вместо «токен есть И он имеет право на операцию Y с ресурсом Z».
2. Неверная привязка объекта к пользователю (IDOR)
Insecure Direct Object References — классика, которая в API проявляется особенно ярко. Пользователь делает запрос GET /api/v1/invoices/12345. Сервер проверяет токен, но не проверяет, принадлежит ли накладная с ID 12345 именно этому пользователю или его компании. Если контроль доступа на уровне объектов отсутствует, злоумышленник может просто перебирать ID, получая чужие данные. Защита — обязательная проверка на каждом эндпоинте: «имеет ли текущий аутентифицированный субъект право работать с этим конкретным объектом?».
3. Слепая вера в валидность структуры токена
Разработчики часто парсят JWT, извлекают из payload user_id и сразу используют его в запросах. Но кто гарантировал, что токен подписан вашим сервером? Если не проверяется криптографическая подпись (алгоритм none, поддельный ключ), то в токен можно вписать любого user_id. Валидация должна включать проверку алгоритма, подписи, срока действия (exp) и издателя (iss). Использование библиотек без понимания их конфигурации — частая причина уязвимостей.
4. Утечка чувствительных данных в ответах API
Это ошибка, связанная с избыточными правами. Допустим, запрос на GET /api/v1/me возвращает полный профиль пользователя, включая внутренние ID, хеши паролей, служебные поля. Другой пример: ответ на запрос списка заказов возвращает не только свои заказы, но и технические поля, например, internal_comment или cost_price, которые не должны покидать внутренний контур. Проблема усугубляется, когда одно и то же API используют и фронтенд, и мобильное приложение, и партнёры — но для всех возвращается одинаковый объём данных.
5. Отсутствие контроля частоты запросов (Rate Limiting) на уровне авторизации
Без лимитов можно бесконечно пытаться подобрать токен, проверять валидность украденных ключей или атаковать логику восстановления пароля через API. Rate limiting должен быть не только глобальным, но и привязанным к учётной записи или токену. Особенно это важно для эндпоинтов, связанных с аутентификацией, регистрацией, верификацией кодов.
Как проектировать API с учётом этих ошибок
Исправление ошибок по одной — путь в никуда. Нужен системный подход на уровне проектирования.
- Единый шлюз авторизации (API Gateway): Вынесите базовые проверки (валидация JWT, проверка scope, rate limiting) на уровень шлюза. Это гарантирует, что некорректный запрос не дойдёт до бизнес-логики.
- Явная модель разрешений: Определите чёткую матрицу: «роль/scope → ресурс → действие». Реализуйте её в виде middleware или декораторов в коде. Не полагайтесь на разрозненные проверки внутри методов.
- Принцип минимальных привилегий для токенов: Выдавайте токены с минимально необходимым набором прав. Для мобильного клиента — один scope, для партнёрской интеграции — другой, для внутреннего сервиса — третий.
- Сквозное логирование аудита: Логируйте все попытки доступа с идентификатором пользователя, токена, ресурса и результатом (разрешено/запрещено). Это необходимо не только для расследования инцидентов, но и для понимания паттернов легитимного использования.
Контекст регуляторики: 152-ФЗ и ФСТЭК
С точки зрения российских требований, безопасность API напрямую касается защиты информации в информационных системах персональных данных (ИСПДн) и государственных информационных системах (ГИС).
Требования ФСТЭК (например, из приказов) акцентируют внимание на управлении доступом. Это не просто «аутентификация», а именно: — Разграничение доступа к информации. — Контроль целостности программной среды. — Регистрация событий безопасности.
Ошибки вроде IDOR или отсутствия проверки scope — прямое нарушение принципа разграничения доступа. API, который позволяет получить чужие персональные данные из-за слабой привязки объекта, не соответствует базовым требованиям. Rate limiting и валидация токенов входят в меры по противодействию НСД (несанкционированному доступу).
152-ФЗ обязывает оператора ПДн обеспечивать безопасность при их обработке. Утечка данных через избыточный ответ API или из-за недостаточной авторизации может быть расценена как нарушение требований закона о защите ПДн. Важно, что ответственность лежит не только на «утечке», но и на отсутствии адекватных мер, которые могли бы её предотвратить. Наличие задокументированной модели управления доступом к API, сквозного аудита и тестов на проверку авторизационных сценариев, это уже часть доказательства выполнения требований.
Практические шаги для аудита своего API
- Картографирование эндпоинтов и прав: Составьте таблицу всех методов API, требуемых ролей/scopes и правил привязки объекта к пользователю.
- Тестирование с изменёнными параметрами: Для каждого эндпоинта, работающего с объектами (по ID), попробуйте выполнить запрос с токеном одного пользователя, но с ID объекта другого пользователя.
- Анализ ответов: Проверьте, не возвращаются ли в ответах чувствительные или избыточные данные. Сравните ответы одного эндпоинта для разных ролей.
- Валидация токенов: Убедитесь, что используется стойкая криптография для подписи, проверяется алгоритм, срок действия. Попробуйте отправить поддельный токен с алгоритмом
none. - Проверка лимитов: Протестируйте, можно ли вызвать критичный эндпоинт (сброс пароля, отправка кода) сотни раз подряд с одного токена или IP.
Безопасность API, это непрерывный процесс, а не разовая настройка. Основные ошибки авторизации происходят из-за разрыва между простой проверкой «кто ты?» и сложным требованием «что тебе здесь можно?». Устранение этого разрыва — ключ к созданию устойчивых систем, которые соответствуют не только техническим, но и регуляторным ожиданиям.