Как защитить REST API в 2026 году

Wed Aug 19 2026

Но OWASP API Security Top 10 для 2026 года не существует. Текущим официальным изданием остаётся OWASP API Security Top 10 2023. Год в этом руководстве — это дата публикации и контекст текущих рекомендаций, а не новый релиз OWASP.

В этом списке 2023 года на первом месте находится BOLA. В нём также перечислены Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Security Misconfiguration и Improper Inventory Management среди рисков. OWASP ранжирует риски. В отчёте 42Crunch State of API Security 2026 представлены сведения об уязвимостях в отобранном поставщиком наборе данных. Эти измерения отвечают на разные вопросы.

Это руководство превращает лучшие практики безопасности REST API в средства контроля, которые можно тестировать до выпуска. Путь запроса проходит через транспорт, идентичность, разрешения, входные данные, средства защиты от злоупотреблений, данные, наблюдаемость и проверку. Авторизация и валидация получают больше всего внимания, потому что «используйте HTTPS» легко настроить; именно при определении того, кто и какой объект может изменять, API чаще всего дают сбой.

В этой статье

Разместите независимые средства контроля в пути запроса

Gateway может отклонить токен, в то время как ваше приложение всё ещё возвращает заказ другого tenant. Средства контроля должны оставаться отдельными, даже если инфраструктура размещает несколько из них в одном сервисе.

  1. TLS защищает соединение.
  2. Gateway может обрабатывать маршрутизацию, базовые проверки токенов или квоты.
  3. Аутентификация устанавливает личность вызывающей стороны.
  4. Авторизация определяет, может ли эта сторона использовать endpoint и обращаться к объекту.
  5. Валидация проверяет форму и смысл входных данных.
  6. Ограничение частоты запросов контролирует потребление ресурсов.
  7. Приложение возвращает только разрешённые данные.
  8. Журналирование и мониторинг записывают сигналы безопасности.

Эта модель описывает поток управления, а не предписывает топологию программного обеспечения. Поэтому edge-сервис может ограничивать частоту запросов до аутентификации. Позже код приложения может применить более точное ограничение на пользователя.

Как отмечает Postman, «одного средства контроля недостаточно». Руководства Postman и StackHawk также предлагают практические советы по реализации. Они не являются стандартами. Используйте их советы для создания средств контроля, а затем адаптируйте политику к своему приложению.

TLS защищает запрос до того, как его увидит ваш код

Настройте безопасность транспорта до проверки разрешений маршрутов. Поэтому учётные данные, токены и данные запросов должны быть защищены до того, как ваше приложение примет первое решение.

Используйте TLS 1.2 или выше, предпочтительно TLS 1.3. Отключите SSLv3, TLS 1.0, RC4 и 3DES. Используйте сертификаты доверенных центров сертификации, а истечение срока действия и замену сертификатов сделайте закреплённой операционной задачей.

Добавляйте HSTS только тогда, когда каждый охватываемый поддомен поддерживает HTTPS:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Отклоняйте обычный HTTP на edge. Редирект всё ещё позволяет первоначальному запросу пройти незашифрованным, поэтому маршрут с открытым текстом должен завершаться ошибкой.

Для взаимодействия сервис-сервис рассмотрите mutual TLS. Обе стороны предъявляют сертификаты, что даёт внутренним сервисам более надёжную проверку идентичности, чем одно лишь сетевое расположение. Не добавляйте mTLS для каждой интеграции с публичными клиентами; выпуск и ротация сертификатов создают работу, за которую кто-то должен отвечать.

Шифрование транспорта защищает данные при передаче. Хранимые данные требуют отдельной защиты. Используйте стандарт шифрования, требуемый вашей средой, включая AES-256, если это предусмотрено вашей политикой, и управляйте ключами через KMS, Key Vault или HSM. Охватите соответствующие слоям хранения средства контроля, определённые классификацией данных: для полей базы данных и дисков может потребоваться один набор средств контроля. Для реплик и резервных копий может потребоваться другой.

Не храните чувствительные значения в URL. Прокси, веб-серверы, инструменты аналитики и другая инфраструктура обычно записывают строки запросов в журналы.

Аутентифицируйте каждый запрос, а затем отдельно принимайте решение о разрешениях

OAuth 2.0 с access-токенами JWT — один из разумных production-паттернов для делегированного доступа и локальной проверки токенов. JWT — это выбор реализации, а безопасность по-прежнему зависит от того, как вы его проверяете и используете. Используйте документированные правила проверки издателя и выбирайте непрозрачные токены с introspection, когда централизованный отзыв является главным требованием.

Для каждого защищённого запроса проверяйте подпись, срок действия, издателя, аудиторию и требуемые scopes или claims. Краткоживущие access-токены ограничивают окно воздействия; refresh-токены поддерживают более длительные сессии, но требуют собственной политики ротации и отзыва. Для scopes высокого риска рассмотрите introspection. Deny-list — ещё один вариант. Я не могу выбрать границу отзыва для вашего случая в общем руководстве. Зафиксируйте, насколько быстро доступ должен быть прекращён, а затем проверьте это.

Советы по JWT регулярно применяются механически. «Мы используем JWT» ничего не говорит, пока некорректные, просроченные, неправильно подписанные токены, а также токены с неправильным издателем или аудиторией не отклоняются должным образом.

Рассмотрим multi-tenant API заказов:

GET /api/orders/123
Authorization: Bearer <access-token>

Токен идентифицирует вызывающую сторону и может содержать ID пользователя, ID tenant и scopes. Сам по себе он не предоставляет доступ к заказу 123. Следующий слой должен применить политику tenant и ресурса.

API keys подходят для интеграций сервис-сервис. Выдавайте каждой интеграции собственный ключ, ограничивайте его scope, устанавливайте срок действия, выполняйте ротацию и отслеживайте использование. Ключ идентифицирует вызывающее приложение; он не может авторизовать доступ пользователя к заказу другого пользователя.

Для браузерных клиентов определите политику хранения и убедитесь, что access-токены не записываются в постоянное хранилище браузера без явно разработанного решения безопасности. Frontend не является границей безопасности.

Вывод о пропущенной аутентификации в отчёте 42Crunch основан на отобранных поставщиком случаях 2025 года; он не измеряет универсальную частоту взломов. Моё суждение проще: сначала тестируйте отсутствие аутентификации, потому что такую ошибку дёшево обнаружить и дорого оправдать. Защищённый маршрут без токена должен возвращать 401.

Авторизация требует больше инженерной работы, чем настройка TLS

OWASP перечисляет Broken Object Level Authorization, или BOLA, как API1:2023. Предсказуемые пути, такие как /api/orders/123, упрощают систематический перебор объектов.

Опасная реализация проверяет только, что вызывающая сторона вошла в систему:

// WRONG: authentication exists, ownership does not
const order = await Order.findById(req.params.id);

Для API, где членство в tenant предоставляет доступ ко всем заказам этого tenant, привяжите поиск к tenant:

// Correct only when tenant membership grants order access
const order = await Order.findOne({
  _id: req.params.id,
  tenant_id: req.user.tenant_id
});

Этот запрос достаточен только в том случае, если членство в tenant является полной политикой. Если доступ также зависит от индивидуального владения, роли, состояния заказа или другого бизнес-правила, добавьте соответствующее условие или проверку политики. Отдельно тестируйте членство в tenant и владение объектом, если важны оба фактора.

Предположим, пользователь A принадлежит tenant North, а пользователь B — tenant South. Пользователь A, запрашивающий /api/orders/123, должен получить задокументированный нераскрывающий 404 и не должен получить данные заказа, если заказ 123 принадлежит South. Пользователь того же tenant без разрешения должен получить 403, если ваш контракт различает этот случай. Не выбирайте 404, если клиентам необходимо различать ошибки авторизации.

Повторите тест с:

PATCH /api/orders/123

Ответ не должен изменить запись. Безопасное чтение не означает безопасную запись.

Применяйте авторизацию на четырёх уровнях:

  • Endpoint: может ли эта идентичность вызвать маршрут?
  • Object: может ли вызывающая сторона получить доступ к этому заказу?
  • Property: может ли вызывающая сторона изменить каждое отправленное поле?
  • Function: может ли эта роль выполнить административную операцию?

Обычный пользователь может изменить примечание о доставке, но никогда не должен изменять tenant_id, цену, состояние платежа или внутреннюю роль. Явные allowlist полей предотвращают массовое присваивание. Используйте RBAC, когда разрешения чётко соответствуют ролям; используйте ABAC, когда решения зависят от tenant, владения, региона или состояния заказа.

Валидация входных данных должна охватывать пути, запросы и тела

В отчёте 42Crunch сломанная валидация входных данных, включая инъекции, массовое присваивание и обход пути, названа наиболее распространённой категорией дефектов в отобранном наборе данных. Это наблюдаемая частота, а не рейтинг рисков OWASP.

Определите допустимую форму запроса и отклоняйте всё остальное. Проверяйте обязательные поля, типы, длины и диапазоны. Также проверяйте форматы, значения enum и вложенные объекты. Валидируйте параметры пути и запроса. Система схем, такая как Joi, Zod или JSON Schema, хранит правила в одном месте.

Используйте следующую последовательность на границе:

  1. Подтвердите метод и Content-Type.
  2. Выполните разбор по строгой схеме.
  3. Проверьте параметры пути и запроса по allowlist.
  4. Установите ограничения размера тела и коллекций.
  5. Отклоняйте неизвестные поля до бизнес-логики или обращения к базе данных.

JSON-тело — лишь один канал ввода. /api/orders/123, ?status=pending, заголовки, типы содержимого и размеры payload также контролируются пользователем.

Такой ввод никогда не должен становиться непроверенным оператором базы данных:

/api/users?status[$ne]=inactive

Разрешайте только документированные ключи запроса и скалярные значения. Негативный тест должен возвращать 400, при этом запрос к базе данных с использованием вложенной формы оператора выполняться не должен.

Авторизация PATCH относится к описанной выше модели разрешений. Слой валидации должен обеспечивать итоговую схему: отклоняйте поля, которые вызывающая сторона не имеет права отправлять, вместо того чтобы молча привязывать их к модели базы данных. Некорректный ввод должен возвращать 400 без stack traces, фрагментов SQL или внутренних данных базы.

Ограничения частоты запросов должны учитывать стоимость endpoint

Единое глобальное ограничение частоты удобно, но не учитывает специфические для endpoint затраты злоупотреблений. У входа в систему и сброса пароля один профиль злоупотреблений. У платежей и операций записи — другой. У списков только для чтения — свои расходы.

  • Вход и сброс пароля: используйте пороги на IP и аккаунт; возвращайте 429 и Retry-After после документированного лимита.
  • Списки заказов только для чтения: используйте более высокий лимит на пользователя, tenant или ключ; отслеживайте scraping.
  • Запись заказов: применяйте более строгие ограничения на пользователя и tenant, поскольку операции записи потребляют больше бизнес-ресурсов.
  • POST /api/payments: применяйте строгий лимит для клиента и требуйте idempotency key, чтобы повторы не создавали дублирующие списания.

Рассмотрите измерения на пользователя, IP, tenant и API key там, где они соответствуют вашей модели угроз. Когда клиент превышает определённое провайдером окно, возвращайте:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1700000000

Эти значения приведены для иллюстрации. Укажите фактическое окно и измерение идентичности рядом с политикой.

Я не знаю форму вашего легитимного трафика, поэтому не буду предписывать универсальное число. Настраивайте параметры на основе телеметрии. Чрезмерно агрессивные ограничения создают ложные срабатывания; слишком щедрые превращают дорогие endpoint в общедоступные ресурсы.

Храните секреты и возвращайте меньше данных, чем содержит база данных

Никогда не встраивайте в код учётные данные, ключи подписи, пароли базы данных или API keys. Удаление секрета из текущей ветки не удаляет его из истории репозитория.

Используйте переменные окружения для простых развёртываний и выделенный secrets manager для управляемого доступа. Ограничивайте учётные данные минимальным полезным набором разрешений, назначайте сроки действия и выполняйте ротацию после предполагаемого раскрытия. Отслеживайте использование на предмет необычного объёма или источника.

Аутентификация и авторизация могут пройти успешно, а ответ всё равно раскроет слишком много. Явно выбирайте поля. Клиенту, запрашивающему отображаемое имя, не нужны хэши паролей, внутренние ID, роли, метаданные tenant или полная запись пользователя.

Ошибки production должны быть общими и содержать ID запроса:

{
  "error": "request_failed",
  "request_id": "7f3c2a91"
}

Подробный серверный контекст записывайте в журнал с привязкой к этому ID. Возвращайте одинаковое внешнее поведение ошибки для случаев «пользователь не найден» и «неправильный пароль», чтобы вызывающие стороны не могли перечислять аккаунты.

Записывайте сигналы, не создавая вторую утечку

Записывайте успешную и неуспешную аутентификацию, ошибки авторизации и нарушения ограничений частоты. Также записывайте изменения чувствительных ресурсов, необычный объём запросов и обращения к несуществующим endpoint. Эти события дают расследованию полезную историю без необходимости сохранять полные тела запросов.

Не записывайте в журнал пароли, access-токены, номера платёжных карт или полные тела чувствительных запросов. Редактирование должно происходить до того, как событие попадёт в хранилище.

Полезные эвристики обнаружения включают:

  • резкий рост ответов 401 может указывать на credential stuffing;
  • скопление ответов 500 вокруг одного endpoint может указывать на попытку эксплуатации;
  • повторяющиеся ответы 403 для соседних ID объектов могут указывать на перебор авторизации;
  • нарушения ограничения частоты, сосредоточенные на одном ключе, могут указывать на скомпрометированную интеграцию.

Эти сигналы требуют расследования, а не автоматических выводов. Ответственные за оповещения должны иметь возможность проверить ID запроса, маршрут, безопасный идентификатор субъекта и статус ответа, не раскрывая секреты.

Ведите инвентаризацию документированных API, версий, сред и маршрутов. У каждого развёрнутого маршрута должны быть ответственный, требование аутентификации, классификация данных, версия и статус вывода из эксплуатации. Инвентаризация — это способ реализовать задачу, лежащую в основе API9:2023: недокументированные или устаревшие маршруты должны иметь ответственного и план удаления.

Оценивайте сроки жизни токенов, ограничения частоты и пороги оповещений с учётом вашего трафика. Это руководство может определить средства контроля, но не может выбрать за вас эти операционные значения.

Докажите эффективность средств контроля до выпуска

Запускайте негативные тесты в CI/CD, а затем повторяйте их во время аудитов и независимых тестов на проникновение.

Аутентификация и авторизация

  • Защищённый маршрут без токена должен возвращать 401.
  • Действительный токен должен достигать ожидаемого обработчика.
  • Просроченные, некорректные, неправильно подписанные токены, а также токены с неправильным издателем или аудиторией должны возвращать 401.
  • Аутентифицированный токен без требуемого scope должен возвращать 403, если только API не документирует нераскрывающий 404.
  • Запрос пользователя A к заказу пользователя B должен возвращать задокументированный межтенантный 404 и не возвращать данные.
  • Пользователь того же tenant без требуемого разрешения на заказ должен получить 403, если контракт различает этот случай.
  • Отклоните запрос пользователя A PATCH /api/orders/123 с запрещёнными полями и оставьте запись неизменной.

Валидация и злоупотребления

Отправляйте отсутствующие поля, некорректные значения пути и запроса, а также payload чрезмерного размера. Тестируйте строки инъекций, неизвестные поля и неожиданные типы содержимого. Ожидайте 400 без внутренних данных.

Превышайте задокументированную квоту каждого endpoint. Ожидайте 429 с Retry-After. Повторите платёжный запрос с одним idempotency key и подтвердите, что он создаёт одну транзакцию.

Проверьте, что поля журнала, содержащие секреты, редактируются, а ошибки production содержат ID запросов без stack traces. Автоматические сканеры обнаруживают повторяемые дефекты; они не могут вывести ваши правила tenant и бизнеса. Добавьте независимое тестирование на проникновение, когда этого требует риск API.

Используйте этот контрольный список безопасности API во время выпуска

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

  • Транспорт: проверены TLS 1.2+, HSTS, если все охватываемые поддомены поддерживают HTTPS, и отклонение обычного HTTP; для mTLS принято явное решение по взаимодействию сервис-сервис.
  • Аутентификация: защищённые маршруты отклоняют отсутствующие, просроченные, некорректные, неправильно подписанные токены, а также токены с неправильным издателем или аудиторией, возвращая 401.
  • Жизненный цикл токенов: access-токены имеют короткий срок действия; поведение ротации и отзыва refresh-токенов задокументировано и протестировано.
  • Авторизация: проверки endpoint, функции, объекта, tenant и полей применяются в коде приложения.
  • Входные данные: проверки тела, пути, запроса, типа содержимого, неизвестных полей и размера возвращают 400; отклонённые операторы запроса никогда не достигают базы данных.
  • Средства защиты от злоупотреблений: специфичные для endpoint ограничения используют задокументированные измерения на пользователя, IP, tenant или ключ; превышение возвращает определённые провайдером 429 и Retry-After.
  • Транзакции: endpoint платежей и транзакций используют idempotency keys, а поведение при дублирующих запросах протестировано.
  • Хранимые данные: чувствительные слои хранения, включая соответствующие резервные копии и реплики, зашифрованы; ключами управляют через KMS, Key Vault или HSM.
  • Секреты: проверки репозитория и сканирование секретов не обнаружили действующих учётных данных; исторические находки отозваны, заменены и зафиксированы.
  • Ответы: возвращаются только необходимые поля; ошибки production содержат ID запросов и не содержат stack traces или внутренних данных.
  • Наблюдаемость: события аутентификации, авторизации и ограничения частоты записываются без секретов. Также записываются чувствительные изменения, аномалии и несуществующие маршруты. Ответственные за оповещения назначены.
  • Инвентаризация: у каждого развёрнутого маршрута есть ответственный, версия, требование аутентификации, классификация данных и статус вывода из эксплуатации.
  • Проверка: тесты безопасности запускаются в CI/CD, аудиты запланированы, а у тестирования на проникновение есть ответственный и дата.

Выпускайте только тогда, когда каждая строка имеет статус «пройдено», «не пройдено» или письменное исключение, а также ответственного и результат теста. Если в задаче написано только «мы используем JWT» или «этим занимается gateway», верните её на доработку.