Главная мысль
Для каждой конечной точки определите способ аутентификации, проверку прав на конкретный объект, допустимую схему запроса и чувствительные данные, которые нельзя возвращать в ответе.
Что определяет конечная точка API
API позволяет программам обмениваться данными и выполнять операции по заранее заданным правилам. Конечная точка — это URL ресурса на сервере или в сервисе вместе с применяемым к нему методом: клиент отправляет запрос, сервис возвращает ответ. Например, GET /accounts/{id} может обозначать чтение, а POST /payments — создание платежа. Знание URL само по себе не даёт права на ресурс.
Ресурс
Определяет доступные данные или операцию.
Идентификация и разрешение
Проверяет, кто отправил запрос и что он может делать с ресурсом.
Ответ
Возвращает только нужные данные и не раскрывает внутренние настройки или секреты.
Разделяйте конечные точки /health и /info
/health обычно возвращает краткий сигнал о работе процесса или сервиса; оркестратор и мониторинг могут использовать его для решения о готовности или перезапуске. В Kubernetes при достижении порога неудачных liveness-проверок перезапускается контейнер, а readiness исключает неготовый pod из получателей нового трафика Kubernetes Service. Это не правило сетевой безопасности, блокирующее любой доступ к pod. /info может показывать версию приложения и метаданные сборки. Название конечной точки не гарантирует стандартного поведения: вы определяете содержимое, уровень доступа и сетевую область. Не возвращайте в публичном ответе секреты, переменные среды, внутренние адреса, точные версии компонентов и чувствительный статус зависимостей; ограничьте диагностические данные и при необходимости требуйте аутентификацию.
Надёжная аутентификация и разрешения на уровне объекта
Обязательно используйте HTTPS для всего трафика API. Проверяйте личность пользователя или сервиса подходящим механизмом; ограничивайте срок действия, аудиторию и область действия токена, не храните секреты в репозитории кода. Для каждого запроса повторно проверяйте на сервере разрешение на конкретный объект и операцию: аутентификация пользователя не даёт доступа к чужому аккаунту или административной функции. Выдавайте сервисам отдельные идентификаторы и минимально необходимые права.
Защищайте входные данные и запросы к базе данных
Проверяйте размер, тип содержимого и схему запроса на сервере; явно определите допустимые поля и форматы. Не собирайте SQL-запросы конкатенацией пользовательского текста. Параметризованные запросы отделяют значения от SQL-кода и служат основной защитой от SQL-инъекции. Проверка данных полезна как дополнительный слой, но не заменяет параметризацию. Давайте учётной записи базы только необходимые таблицы и операции, не показывайте пользователю подробные сообщения об ошибках и храните пароли с подходящим медленным хешированием и солью.
Ограничивайте потребление ресурсов и тестируйте конечные точки
Ограничивайте не только частоту запросов, но и пагинацию, размер тела, стоимость тяжёлого поиска и экспорта. Лимиты должны учитывать сценарии до и после аутентификации, а также использование по учётной записи и ключу; одного ограничения по IP может быть недостаточно против распределённых ботов. Не записывайте в журналы персональные данные, токены и пароли; оставляйте достаточно событий для обнаружения, соблюдая правила хранения и доступа. В тестах проверьте неверный токен, идентификатор чужого объекта, лишние поля, слишком большое тело запроса, SQL-синтаксис и срабатывание лимита. Убедитесь, что коды ответа, задержки, ошибки и блокировка соответствуют ожиданиям.