Безпека API: автентифікація, авторизація та вразливості

Чому API є першочерговою ціллю

API стали домінуючим архітектурним патерном для сучасних застосунків — мобільні клієнти, односторінкові застосунки, мікросервіси та сторонні інтеграції спілкуються через них. Така поширеність робить їх привабливою ціллю: одна вразлива кінцева точка API може розкрити дані мільйонів користувачів, обійти автентифікацію або надати несанкціонований адміністративний доступ. OWASP веде окремий список API Security Top 10 саме тому, що вразливості вебзастосунків не повністю охоплюють ризики, специфічні для API.

Автентифікація: підтвердження особи на рівні API

API-ключі

API-ключі — найпростіший механізм автентифікації: статичний секрет, яким ділиться з клієнтом. Вони підходять для комунікації сервер-сервер, де клієнт є довіреною серверною системою. Критичні практики:

• Ставтеся до API-ключів як до паролів: ніколи не записуйте їх у журнали, не включайте в URL (використовуйте заголовок Authorization), не фіксуйте в системі контролю версій
• Видавайте окремі ключі для кожного клієнта, щоб можна було відкликати окремі ключі без відключення інших
• Встановлюйте дати закінчення та регулярно ротуйте ключі
• Обмежуйте ключі мінімально необхідними дозволами

Автентифікація на основі JWT

JWT (JSON Web Tokens) кодують заявки, які сервер може перевірити без звернення до бази даних, що робить їх популярними для stateless API. JWT складається із заголовка, корисного навантаження та підпису: header.payload.signature, кожна частина кодується Base64URL.

Критичні кроки валідації:

1. Перевірте підпис із використанням правильного алгоритму (відхиляйте alg:none)
2. Перевірте, що iss (видавець) відповідає очікуваному центру сертифікації
3. Перевірте, що aud (аудиторія) — це ваш API
4. Перевірте exp (термін дії) — відхиляйте прострочені токени
5. Перевірте nbf (не раніше ніж), якщо присутній

Ніколи не довіряйте полю alg у заголовку токена для визначення логіки валідації — завжди фіксуйте очікуваний алгоритм на стороні сервера.

Scope OAuth для авторизації

Для API, орієнтованих на користувача, використовуйте OAuth 2.0 із детальними scope-ами: read:profile, write:orders, admin:billing. Кожна кінцева точка API повинна перевіряти, що наданий токен містить необхідний scope. Валідний токен не означає доступу до всього.

OWASP API Security Top 10: критичні ризики

Порушення авторизації на рівні об'єктів (BOLA)

BOLA — також відоме як IDOR (Insecure Direct Object Reference) — стабільно займає перше місце серед ризиків безпеки API. Воно виникає, коли кінцева точка API приймає ідентифікатор об'єкта в запиті, але не перевіряє, чи справді запитувач є власником цього об'єкта:

GET /api/orders/12345  →  повертає замовлення 12345
GET /api/orders/12346  →  повертає замовлення іншого користувача (BOLA!)

Захист: для кожної кінцевої точки доступу до об'єктів перевіряйте, що автентифікований користувач має відношення до запитуваного об'єкта. Ніколи не покладайтеся лише на ідентифікатор об'єкта.

Порушення авторизації на рівні функцій

Адміністративні функції доступні за передбачуваними URL, але покладаються на приховування на стороні клієнта, а не на примусове застосування на стороні сервера:

POST /api/admin/deleteUser  →  доступно звичайним користувачам

Захист: застосовуйте контроль доступу на основі ролей до кожної кінцевої точки на стороні сервера. Регулярно тестуйте всі кінцеві точки незалежно від того, чи з'являються вони в інтерфейсі для вашої ролі.

Порушення авторизації на рівні властивостей об'єктів

API може правильно обмежувати доступ до об'єктів, але розкривати або дозволяти модифікацію внутрішніх полів цих об'єктів:

PUT /api/users/me  {"role": "admin"}  →  вразливість масового присвоєння

Захист: використовуйте явні allowlist-и для полів, які можна читати або записувати для кожної кінцевої точки. Ніколи не передавайте об'єкти тіла запиту безпосередньо до методів ORM (наприклад, update(params[:user]) у Rails без permit).

Необмежене споживання ресурсів

Без обмеження частоти запитів один клієнт може вичерпати обчислювальні ресурси вашого API, з'єднання з базою даних або квоту сторонніх сервісів:

• Впроваджуйте обмеження частоти запитів для кожного користувача, кожного IP та кожного API-ключа
• Повертайте 429 Too Many Requests із заголовками Retry-After
• Обмежуйте розмір тіла запиту, щоб запобігти DoS через надмірно великі корисні навантаження
• Використовуйте пагінацію та обмежуйте результати: ніколи не повертайте необмежені колекції
• Застосовуйте обмеження глибини запитів для GraphQL API

Використовуйте інструменти на зразок модуля limit_req nginx, обмеження частоти AWS API Gateway або спеціалізованих API-шлюзів (Kong, Envoy) для обмеження частоти запитів.

Неправильна конфігурація безпеки

Поширені неправильні конфігурації API включають:

• CORS встановлено як Access-Control-Allow-Origin: * на автентифікованих кінцевих точках
• Детальні повідомлення про помилки, що розкривають стеки трасування, запити до бази даних або внутрішні шляхи
• HTTP-методи не обмежено (PUT/DELETE увімкнено там, де мають бути лише GET/POST)
• Відсутність примусового застосування HTTPS
• Документація Swagger/OpenAPI публічно доступна в продакшені

Вразливості бізнес-логіки

Не всі вразливості API є технічними — деякі експлуатують саму бізнес-логіку:

• Застосування промокоду зі знижкою кілька разів
• Переказ від'ємної суми для поповнення рахунку
• Пропуск обов'язкових кроків оплати шляхом прямого виклику пізнішої кінцевої точки API

Для виявлення таких вразливостей необхідні знання предметної галузі, і автоматизовані сканери не здатні їх виявити. Включайте тестування бізнес-логіки в огляди безпеки API.

Практичне посилення безпеки API

• Використовуйте HTTPS скрізь і перенаправляйте HTTP на HTTPS; встановлюйте заголовок Strict-Transport-Security
• Валідуйте всі вхідні дані — відхиляйте несподівані поля, валідуйте типи, діапазони та формати
• Повертайте мінімум даних — не включайте внутрішні ідентифікатори, серверні часові мітки або системні метадані у відповіді
• Журналюйте всі виклики API із достатнім контекстом (ID користувача, кінцева точка, код відповіді, тривалість) для криміналістичного аналізу
• Використовуйте API-шлюз для централізованої автентифікації, обмеження частоти запитів, журналювання та виявлення загроз
• Тестуйте за допомогою OWASP ZAP або Burp Suite відповідно до документації вашого API — кожна кінцева точка у вашій специфікації OpenAPI має бути протестована на обхід автентифікації та BOLA