Авторизация и безопасность API за 8 минут

Проверки доступа дают самые дорогие баги: один пропущенный IDOR раскрывает данные всех клиентов. На собесах middle и senior про это спрашивают обязательно.

Два шага

• Аутентификация: кто ты. Ошибка даёт 401 (нет токена, неверный, просроченный).
• Авторизация: что тебе можно. Ошибка даёт 403.

Способы аутентификации

• Basic: Authorization: Basic YWRtaW46cXdlcnR5. Это admin:qwerty в Base64, то есть кодирование, а не шифрование. Только по HTTPS.
• API-ключ в заголовке (X-API-Key). В query-строке опасно: адрес оседает в логах и истории.
• Сессионная cookie: сервер хранит сессию, браузер шлёт sid.
• Bearer-токен: Authorization: Bearer <токен>, часто JWT.
• OAuth 2.0 и OpenID Connect: вход через провайдера и делегирование доступа.
• mTLS: клиентский сертификат, встречается между сервисами и в банках.

JWT

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiZXhwIjoxNzkyMDAwMDAwfQ.<подпись>

Три части через точку: header (алгоритм), payload (claims), signature. Первые две части это Base64URL, их прочитает кто угодно, например на jwt.io. Значит, в payload не должно быть секретов и лишних персональных данных.

Стандартные claims: sub (кто), exp (когда истекает, unix-время), iat (когда выпущен), iss (кто выпустил), aud (для кого).

Подпись не даёт подделать payload. Проверки:

• поменять role в payload без новой подписи: 401;
• "alg": "none" и пустая подпись: 401 (иначе критическая уязвимость);
• подпись своим ключом, токен с другого стенда, exp в прошлом, чужой aud: 401.

JWT сервер обычно не хранит, поэтому отозвать его до exp нельзя без дополнительных механизмов. Отсюда пара токенов: access живёт минуты и ходит в каждом запросе, refresh живёт дольше и нужен только для получения нового access. Проверки: после обмена старый refresh не работает, после выхода refresh отозван, параллельный обмен одного refresh не выкидывает пользователя.

OAuth 2.0 кратко

Потоки (grant types):

• Authorization Code + PKCE: для веба, мобильных и SPA. Пользователя отправляют на сервер авторизации, он входит, приложение получает одноразовый код и меняет его на токен, доказывая владение code_verifier.
• Client Credentials: сервис к сервису, без пользователя.
• Implicit и Password устарели, в OAuth 2.1 их убирают.

OWASP API Security Top 10 (2023)

Первые пять пунктов стоит знать наизусть:

1. BOLA (Broken Object Level Authorization), он же IDOR: подставил чужой id и получил чужой объект.
2. Broken Authentication: слабый вход, нет лимита на подбор, токены не проверяются.
3. Broken Object Property Level Authorization: лишние поля в ответе и mass assignment (прислал "role": "admin" в теле, и оно сохранилось).
4. Unrestricted Resource Consumption: нет лимитов на размер, частоту и стоимость запросов.
5. Broken Function Level Authorization: обычный пользователь вызывает админский метод напрямую.

Как тестировать доступ

1. Заведите минимум двух пользователей каждой роли.
2. Постройте матрицу «роль × эндпоинт × метод» и проверьте каждую клетку.
3. Пройдитесь по чужим id во всех методах, включая PUT и DELETE, а также во вложенных ресурсах (/users/15/orders).
4. Добавьте в тела лишние поля: role, balance, ownerId.
5. Проверьте жизненный цикл: выход, смена пароля, блокировка пользователя.

Скрытая в интерфейсе кнопка не защита: запрос всегда можно отправить из Postman.

На чужой объект API может вернуть 403 или 404. 404 не раскрывает, что объект существует, это допустимо. Главное, чтобы в ответе не было данных.

Частые ошибки

• Путать 401 и 403.
• Считать Base64 шифрованием, а JWT зашифрованным.
• Тестировать права только через интерфейс.
• Проверять IDOR только на GET.

Что спросят на собесе

• Чем аутентификация отличается от авторизации?
• Как устроен JWT и что в нём проверить?
• Зачем нужен refresh-токен?
• Что такое IDOR и как его найти?
• Какие пункты OWASP API Top 10 вы знаете?