12 советов по безопасности API

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Всем

Контекст: API, обзор дизайна REST API, HTTP и HTTPS, интеграционная авторизация. Углубление: уязвимости и атаки на API, проектирование API.

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

---

1. HTTPS

HTTPS шифрует данные при передаче между клиентом и сервером. Без TLS пароли, токены и персональные данные идут по сети в открытом виде.

Типичная схема установки защищённого соединения:

1. Клиент устанавливает TCP-соединение с сервером (порт 443).
2. На этапе TLS handshake стороны обмениваются открытыми ключами и согласуют параметры шифрования.
3. После проверки сертификата генерируется общий сессионный ключ (симметричное шифрование).
4. Дальше по каналу идут уже зашифрованные HTTP-запросы и ответы.

Подробнее — HTTP как основа веб-интеграций, шифрование и SSH. В продакшене дополнительно включают HSTS (Strict-Transport-Security), чтобы браузер не откатывался на HTTP.

---

2. OAuth 2.0

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

Упрощённый поток для веб- и мобильных клиентов:

1. Клиент перенаправляет владельца ресурса (пользователя) на сервер авторизации (Google, корпоративный IdP).
2. Пользователь подтверждает выданные scopes (области доступа).
3. Сервер авторизации возвращает код или сразу токен; клиент обменивает его на access token.
4. С access token клиент обращается к resource server (вашему API).

Для machine-to-machine — grant client_credentials; для браузерных SPA — authorization_code с PKCE. Сравнение JWT и API-ключей, потоки M2M — авторизация в интеграционных сценариях. Общая картина OAuth и SSO — аутентификация и авторизация.

---

3. WebAuthn

WebAuthn (часть стандарта FIDO2) — вход через аппаратный ключ (YubiKey), биометрию устройства или встроенный аутентификатор платформы. Приватный ключ остаётся на устройстве; сервер хранит только публичный ключ для проверки подписи.

Участники протокола:

• Relying party — ваш сервер или API, который запрашивает аутентификацию.
• Client / platform — браузер или ОС, посредник между сайтом и аутентификатором.
• Authenticator — внешний USB/NFC-ключ или встроенный модуль (Touch ID, Windows Hello).

WebAuthn дополняет OAuth и пароли там, где нужен сильный фактор владения без SMS. Подробнее про FIDO2 и аппаратные ключи — аутентификация и авторизация.

---

4. API-ключи с уровнями доступа

Один «мастер-ключ на всё» опасен: при утечке злоумышленник получает полный доступ. Leveled API keys — отдельные ключи (или подписи) под уровень прав:

• ключ только на чтение (GET);
• ключ на запись в конкретный ресурс;
• отдельный ключ для webhook или batch-операций.

Для server-to-server иногда применяют HMAC-подпись запроса: клиент подписывает метод, путь, timestamp и тело секретом; сервер пересчитывает подпись и отклоняет просроченные или подделанные запросы. Жизненный цикл ключей — ротация, отзыв, привязка к client_id. Сравнение с JWT — токены и API-ключи.

---

5. Авторизация

Аутентификация отвечает на вопрос «кто ты?»; авторизация — «что тебе разрешено?». Валидный JWT или API-ключ ещё не означает право читать или менять конкретный объект.

Проверки на каждый запрос:

• может ли этот пользователь просматривать ресурс;
• может ли он изменять или удалять его;
• соответствует ли операция роли и scope токена.

Типичная ошибка — Broken Access Control / IDOR: GET /orders/999 отдаёт чужой заказ, потому что сервер проверил только наличие токена. Модели RBAC и ABAC — аутентификация и авторизация.

---

6. Rate limiting

Rate limiting ограничивает число запросов за интервал времени и защищает API от перегрузки, brute force и простых DoS-атак.

Правила задают в разрезе:

• IP-адреса (анонимный или публичный трафик);
• пользователя или client_id;
• группы операций (строже на /login, /reset-password, дорогие POST).

При превышении лимита — 429 Too Many Requests, заголовки X-RateLimit-* и по возможности Retry-After. Алгоритмы (token bucket, sliding window) — rate limiting в «12 концепциях» и разбор в статье про атаки.

---

7. Версионирование API

Версия в URL или заголовке фиксирует контракт и даёт менять API без поломки старых клиентов.

Подход	Пример
В пути	GET /v1/users/123
Без версии	GET /users/123 — риск неожиданных изменений для всех клиентов сразу

Партнёрские и мобильные API чаще используют /v1/, /v2/ в пути; внутренние сервисы иногда версионируют через заголовок Accept. Политика deprecation — проектирование API, версии в OpenAPI.

---

8. Whitelist (белые списки)

Явно разрешайте только известные хорошие сущности вместо попыток перечислить всё запрещённое.

Типичные whitelist-правила:

• IP-адреса партнёров на firewall или API Gateway;
• домены для redirect (next= только на свои URL);
• поля в теле запроса (allow-list при обновлении профиля — защита от mass assignment);
• Content-Type и Origin на входе.

Blacklist легко обойти новым вариантом атаки; whitelist задаёт минимально необходимый периметр. IP-фильтрация в интеграциях — проектирование API и интеграций.

---

9. OWASP API Security Top 10

OWASP (Open Web Application Security Project) публикует актуальные списки рисков для веб-приложений и отдельно для API — OWASP API Security Top 10. Туда входят, среди прочего:

• Broken Object Level Authorization (BOLA / IDOR);
• Broken Authentication;
• Unrestricted Resource Consumption;
• Broken Function Level Authorization;
• Security Misconfiguration.

Регулярно сверяйте новые эндпоинты с этим списком и с каталогом угроз. Базовый OWASP Top 10 для веба — информационная безопасность.

---

10. API Gateway

API Gateway — единая точка входа между клиентами (мобильное приложение, браузер, партнёр) и backend-сервисами. На шлюзе централизуют:

• аутентификацию и проверку JWT;
• rate limiting и квоты;
• маршрутизацию /api/v1/* → нужный микросервис;
• валидацию схемы запроса до попадания в бизнес-логику;
• логирование и метрики.

Примеры: Kong, AWS API Gateway, Envoy, Nginx + middleware. Роль gateway в HTTP-стеке — HTTP-экосистема; в архитектуре микросервисов — § в «12 концепциях».

---

11. Обработка ошибок

Ответ об ошибке должен помогать клиенту-разработчику, но не раскрывать внутренности сервера.

Делать	Избегать
Понятный код и сообщение для интегратора (invalid_email, order_not_found)	Stack trace, SQL-запросы, пути к файлам на диске
Корректный HTTP status (400, 401, 403, 404, 422, 500)	200 OK с "success": false или 500 на ошибку валидации
Единый формат ошибок по всему API	Разный JSON в каждом контроллере
correlation-id в ответе для поддержки	Внутренние ID БД без необходимости

Клиенту достаточно знать, что исправить; детали для SRE — в логах и трейсах, не в теле ответа. Примеры утечек — каталог угроз (строка «Утечка в ответе»).

---

12. Валидация входных данных

Любые данные от клиента считаются недоверенными, пока не прошли проверку. Input validation — первая линия обороны от инъекций, переполнений и логических багов.

Проверяют до бизнес-логики (часто на API Gateway или в middleware):

• типы и форматы полей (email, UUID, enum);
• длина строк и размер тела запроса;
• глубина вложенности JSON;
• обязательные и запрещённые поля.

Схемы описывают в OpenAPI и дублируют в коде (JSON Schema, Pydantic, class-validator). SQL- и command-инъекции — инъекции; mass assignment — каталог угроз.

---

Как пользоваться чек-листом

Порядок внедрения

1. Транспорт — HTTPS, HSTS.
2. Идентичность — OAuth 2.0, WebAuthn или ключи с уровнями.
3. Доступ — авторизация на каждый объект, whitelist полей.
4. Периметр — gateway, rate limit, версии в URL.
5. Качество контракта — валидация, безопасные ошибки, сверка с OWASP.

На ревью нового эндпоинта пройдитесь по таблице ниже — «да / нет / N/A» по каждой строке.

#	Практика	Вопрос для ревью
1	HTTPS	Только TLS 1.2+? Нет http:// в продакшене?
2	OAuth 2.0	Пользовательский доступ через стандартный grant с PKCE?
3	WebAuthn	Критичные аккаунты поддерживают FIDO2?
4	Leveled keys	Ключи разделены по scope; есть ротация?
5	Authorization	Проверка владельца ресурса, не только токена?
6	Rate limit	Лимиты на login и дорогие операции?
7	Versioning	Путь /v1/… и политика deprecation?
8	Whitelist	Redirect, IP, поля — allow-list?
9	OWASP	Эндпоинт сверен с API Security Top 10?
10	Gateway	Auth и лимиты централизованы?
11	Errors	Нет stack trace в JSON клиенту?
12	Validation	Схема входа до handler?

---

Связанные материалы

• Уязвимости и атаки на API — IDOR, SSRF, DoS, практический hardening
• Security API — развёрнутый раздел проектирования
• Авторизация в интеграционных сценариях — JWT, mTLS, OAuth M2M
• Проектирование API и интеграций — B2B, webhooks, mTLS