API security basics для QA - это не попытка заменить security engineer или pentest. Это базовый уровень мышления, который помогает не пропускать грубые и дорогие уязвимости в обычном тестовом цикле. Если API принимает данные, меняет состояние системы, отдаёт чувствительную информацию или открывает доступ к операциям, значит у него есть поверхность атаки. И QA очень часто оказывается первым человеком, который может заметить, что защита выглядит слабой.
Важно понимать простую вещь: безопасность API ломается не только через "хакерские" сценарии. Часто проблема выглядит почти как обычный функциональный баг. Пользователь видит чужие данные, может изменить не своё, отправляет лишнее поле и система его принимает, получает слишком подробную ошибку или обходит ограничение, которое UI честно скрывал. Снаружи это может выглядеть как странность поведения. По сути это уже security risk.
Что входит в базовую API security-проверку
На первом уровне QA не нужно пытаться проверять всё. Но есть несколько классов рисков, которые нужно видеть почти всегда:
- →кто вообще может вызвать endpoint
- →к каким данным получает доступ пользователь
- →может ли он работать с чужими объектами
- →не принимает ли API лишние поля и лишние действия
- →не отдаёт ли система больше данных, чем реально нужно
- →не слишком ли подробно она рассказывает об ошибках и внутреннем устройстве
- →как API ведёт себя под повторными запросами, перебором, слишком большими payload и плохими входами
- →насколько безопасно настроены transport и базовые ограничения
Это и есть практический минимум. Не "все возможные атаки мира", а хороший рабочий baseline для ежедневной QA-практики.
Самая важная зона - контроль доступа
Если упростить, то большая часть дорогих API-уязвимостей связана с доступом. Не с тем, что система "взломалась", а с тем, что она неправильно решила, кому что можно.
Для QA здесь особенно важны три вопроса:
- →может ли пользователь получить доступ к чужому объекту
- →может ли выполнить действие, которое его роль делать не должна
- →проверяется ли это на backend, а не только на UI
Это критично, потому что UI очень часто создаёт ложное чувство безопасности. Кнопка скрыта, пункт меню недоступен, поле read-only. Но если backend реально не проверяет доступ, пользователь всё равно может отправить прямой запрос и выполнить действие.
Поэтому сильная API security-проверка почти всегда включает попытки:
- →открыть чужой ресурс по подменённому ID
- →изменить объект другой роли или другого пользователя
- →вызвать административный endpoint обычным пользователем
- →выполнить запрещённую операцию напрямую через API, даже если UI не даёт этого сделать
Если такие вещи проходят, это уже не просто баг доступа. Это серьёзная уязвимость.
Избыточные данные и mass assignment
Вторая очень важная зона - данные, которые API принимает и возвращает.
API может быть уязвимым, даже если доступ формально проверяется. Например:
- →в ответе есть лишние поля, которые клиенту не нужны
- →backend возвращает внутренние идентификаторы, служебные флаги или чувствительные атрибуты
- →клиент отправляет поле, которое вообще не должен контролировать, а backend его принимает
- →можно изменить статус, роль, цену, ownership или другой чувствительный атрибут просто потому, что поле есть в body
Для QA это означает две полезные привычки.
Первая - смотреть не только на то, что "нужно для сценария", но и на весь response целиком. Если система отдаёт больше, чем нужно, это уже повод задуматься.
Вторая - пробовать отправлять неожиданные поля. Не ради хаоса, а чтобы проверить, насколько backend действительно контролирует контракт. Если пользователь может сам передать role=admin, is_verified=true или чужой owner_id, и система это молча принимает, риск очень высокий.
Ошибки, конфигурация и transport
Не все security-проблемы выглядят как доступ к чужим данным. Иногда API ломается на более базовом уровне.
Что полезно замечать QA:
- →работает ли всё только по HTTPS
- →не утекают ли токены, API keys и чувствительные данные в URL
- →не возвращает ли система stack trace, внутренние пути, SQL-ошибки, конфигурацию или слишком подробные диагностические сообщения
- →не принимает ли неожиданные Content-Type
- →нет ли странно широких CORS-настроек
- →есть ли базовые ограничения на размер запроса и частоту вызовов
- →как система ведёт себя при переборе, частых повторах и слишком больших payload
Это те вещи, которые не всегда требуют deep security expertise, но уже дают QA сильный сигнал: продукт ведёт себя безопасно или слишком доверчиво.
Почему negative testing здесь особенно полезен
API security basics очень тесно связаны с negative API testing. Только тут плохой запрос нужен не просто чтобы проверить валидацию, а чтобы проверить границы защиты.
Например, полезно пробовать:
- →просроченный токен
- →токен другого пользователя
- →отсутствующую авторизацию
- →неожиданные поля в body
- →чужой ID в path или query
- →запрещённый HTTP method
- →слишком большой payload
- →слишком частые запросы подряд
- →комбинации параметров, которые не должны работать вместе
Для QA важен не только сам ответ, но и побочный эффект. Даже если API вернул ошибку, нужно проверить, что данные реально не изменились, операция не сработала частично и система не оставила после себя битое состояние.
Практический пример
Представь API обновления профиля: PATCH /users/{id}
Что здесь важно QA с точки зрения security:
- →может ли пользователь обновить только свой профиль
- →что произойдёт, если подставить чужой id
- →можно ли отправить вместе с именем и телефоном поля вроде role, is_admin, status, email_verified
- →не возвращает ли ответ лишние внутренние поля
- →не раскрывает ли ошибка, существует ли конкретный пользователь и как именно устроена backend-логика
- →что будет без токена, с чужим токеном, с просроченным токеном
- →не принимает ли endpoint неожиданный Content-Type
- →не появляется ли частичное обновление, если часть полей невалидна
Внешне это обычный endpoint профиля. Но именно на таких сценариях очень хорошо видно, защищает ли backend систему по-настоящему или просто надеется на корректное поведение клиента.
Что должен вынести QA из этой темы
- →API security basics для QA - это про проверку границ доверия, а не про редкие экзотические атаки.
- →Самые важные зоны внимания - object-level access, function-level access, лишние данные в ответах и лишние поля в запросах.
- →UI-ограничения нельзя считать защитой, пока backend не проверяет то же самое сам.
- →Security-проблема часто выглядит как обычный функциональный дефект, поэтому QA легко может заметить её раньше других.
- →Даже без отдельного security-тура QA способен сильно снизить риск, если регулярно проверяет доступ, контракт, ошибки и поведение API на плохих входах.
Что ещё почитать
- →Внутри базы: Аутентификация и авторизация
- →Внутри базы: Negative API testing
- →Внешний материал: OWASP API Security Top 10
- →Внешний материал: OWASP REST Security Cheat Sheet
- →Внешний материал: OWASP Authorization Cheat Sheet