Инструменты безопасности API: защитить API — не значит его протестировать

Два семейства инструментов безопасности API

Где одной только защиты оказывается мало

Шлюз не может знать, что пользователь A не должен читать заказ пользователя B. Это бизнес-правило, оно живёт в вашем коде, и любой запрос, который его затрагивает, выглядит на проводе абсолютно легитимным. Правильный метод, валидный токен, корректно составленный путь.

Авторизация на уровне объектов — самая часто эксплуатируемая уязвимость в реальных API, и это ровно тот класс, который не видит ни один защитный слой. Её приходится проверять в самом сервисе, до релиза.

Что на самом деле закрывает каждое семейство

• Шлюзы и межсетевые экраны: известные паттерны атак, некорректно сформированные запросы, объём. Реальная польза — и слепота к логике.

• Ограничение частоты запросов: злоупотребление объёмом. Ничего не делает с одним корректно составленным вредоносным запросом.

• Управление секретами: утечки учётных данных. Ортогонально всему остальному здесь, и иметь его стоит.

• Сканеры: уязвимости в зависимостях, классы инъекций, конфигурация TLS.

• Поведенческая проверка: отказывает ли API в том, в чём должен отказать. Самое дешёвое и чаще всего отсутствующее.

Почему этот пробел сохраняется

Поведенческая проверка авторизации дёшева, даёт высокую отдачу и повсеместно отсутствует — странное сочетание, которое стоит объяснить.

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

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

Проверка, которую стоит провести на этой неделе

Создайте две учётные записи. Пусть одна создаст запись. Попробуйте прочитать её токеном второй. Если данные вернулись — у вас самая распространённая серьёзная уязвимость API, и никакой шлюз перед вашим сервисом её бы не остановил.

Затем автоматизируйте её, потому что эту проверку придётся повторять для каждого нового эндпоинта, а помнить об этом никто не будет.

Если ничего устанавливать не хочется, то же самое делает дашборд. Всё остальное, что умеет командная строка, — в репозитории CLI.

Сгенерированные планы для API включают категории авторизации и граничных значений, поэтому такие проверки идут рядом с функциональным покрытием, а не ждут ежеквартального мероприятия. Механика описана в документации по тестированию API.

Подключите репозиторий из дашборда — и запуски будут стартовать от того деплоя, который вы и так собираете; либо вместо этого добавьте шаг в свой рабочий процесс.

Что TestSprite закрывает в семействе проверки

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

Он работает с запущенным сервисом через его интерфейс, опираясь на обнаружение и вашу спецификацию. Auto-Authentication поддерживает сессии живыми на протяжении прогона, Dynamic Variables переносят значения между вызовами, Dependency Chains выводят порядок выполнения, а Auto-Cleanup удаляет ровно то, что прогон создал.

Выигрыш — в регулярности. Эти проверки несложны, но про сороковой эндпоинт о них легко забыть, и именно их запуск на каждое изменение закрывает самый часто эксплуатируемый пробел в реальных API. А ваш шлюз и ваш сканер продолжают делать то, что у них получается хорошо.