Security testing проверяет, защищает ли система данные и действия при нежелательном использовании. Для QA это продолжение обычного вопроса «правильно ли работает функция»: можно ли получить чужой файл, повторить действие без права, сохранить опасные данные или обойти ограничение прямым запросом.
Базовая security-проверка не требует начинать с набора атакующих строк. Намного полезнее понять активы, пользователей, границы доверия и последствия ошибки. Тогда тест связан с реальным риском продукта и даёт воспроизводимое доказательство.
Определить область и условия проверки
Используй согласованное окружение, тестовые аккаунты и подготовленные данные. Зафиксируй доступные роли, endpoints, интеграции, разрешённые виды проверок и ограничения стенда. Тест, создающий много запросов или влияющий на доступность, требует отдельного согласованного профиля: он отличается от обычного контроля прав.
Опиши, какие операции должны быть возможны, а какие запрещены. Это основа для ожидаемых результатов. Если роль менеджера видит все заказы своей команды, её доступ к такому заказу может быть нормальным поведением; без правил ownership легко зарегистрировать ложную уязвимость.
Начать с активов и границ доверия
Перечисли то, что продукт должен защищать: персональные данные, деньги, документы, токены, административные действия, доступность. Затем нарисуй путь данных через браузер, API, очередь, хранилище и внешние сервисы. На переходах между компонентами часто возникают неверные предположения о доверии.
Клиентское приложение не должно само определять разрешённую цену или владельца объекта только потому, что поле скрыто. Значение, пришедшее из импорта или партнёрского сервиса, тоже не становится автоматически безопасным. QA проверяет применение правил на каждой существенной границе.
Разделять аутентификацию и авторизацию
Аутентификация подтверждает личность, авторизация разрешает конкретное действие. Проверь обе стороны: валидность и истечение сессии, logout, отзыв прав, доступ по роли и принадлежности объекта. Успешный вход пользователя не разрешает ему читать любой документ.
Составь матрицу «роль × объект × действие». Для каждой важной разрешённой операции добавь запрет на чужой объект и недостаточную роль. Выполняй запрос через UI и напрямую через API в тестовом окружении. Скрытая кнопка без серверной проверки не защищает ресурс.
Проверять полный путь данных
Данные могут утекать через ответ API, скачиваемый файл, URL, push, кэш и диагностические логи. Проверяй не только основной экран. После смены аккаунта предыдущие приватные документы не должны оставаться доступны там, где продукт обещает разделение данных.
Для ввода оцени серверную валидацию и безопасную обработку в месте использования. SQL-параметры должны оставаться данными, пользовательский текст — отображаться в правильном контексте без исполнения. Ограничения размера, типа файла и частоты действий должны проверяться на нужном слое, а не существовать только в клиентской форме.
Как использовать стандарты и инструменты
OWASP ASVS помогает выбрать проверяемые требования к защитным механизмам. WSTG описывает подходы к web-проверкам. Top 10 удобен как карта распространённых классов риска, но не даёт полного покрытия конкретного приложения.
SAST исследует код, DAST — поведение работающего приложения, SCA — состав зависимостей и связанные с ним риски. Эти способы дополняют друг друга. Сканер может пропустить бизнес-ошибку доступа, а найденная уязвимая библиотека требует проверки применимости. Результат инструмента — повод для расследования, а не автоматический приговор релизу.
Практический пример: скачивание отчёта
Подготовь два аккаунта A и B разных тестовых организаций и администратора с описанной областью прав. Создай отчёт в организации A, сохрани его ID и ссылку скачивания. Дальше проверь всю цепочку генерации, статуса и получения файла.
- →A создаёт отчёт и получает файл только со своими данными.
- →B использует ID отчёта A: API не раскрывает статус или содержимое, если политика запрещает такой доступ.
- →B открывает прямую ссылку: результат соответствует модели защиты файла, а знание ID не обходит проверку.
- →После удаления отчёта или истечения разрешённого срока ссылка больше не даёт доступ согласно требованиям.
- →Администратор получает только те возможности, которые закреплены его ролью и областью организации.
Для подписанных временных ссылок явно проверь их предусмотренную модель: кто может использовать ссылку, сколько она действует и когда отзывается. Нельзя ожидать мгновенного отзыва, если архитектура его не обещает; такой остаточный риск нужно обсуждать как требование.
Ошибки и отказ защитного компонента
Защита должна сохранять смысл при исключительных состояниях. Проверь управляемый отказ сервиса проверки прав, недоступность хранилища ключей или повреждённый формат токена в пределах согласованного теста. Ошибка проверки не должна превращаться в разрешение действия.
Сравни ответ с фактическим состоянием. API может вернуть «доступ запрещён», но успеть поставить задание в очередь до проверки. Поэтому после отказа важно убедиться, что отчёт не создан, письмо не отправлено и запись не изменена. Это проверка побочного эффекта, а не только HTTP-кода.
Как оформлять находку и ретест
В отчёте укажи роль, принадлежность объекта, предусловия, точный запрос без секретов, фактический результат и ожидаемую политику. Покажи минимальное доказательство на тестовых данных: достаточно одного недопустимо доступного объекта. Оцени последствия вместе с профильным специалистом, учитывая реальные возможности пользователя.
После исправления проверь исходный сценарий, соседние операции, другие роли и путь через фоновую обработку. Закрытие одной кнопки может оставить тот же дефект в мобильном API или скачивании файла. Подтверждённую проверку стоит включить в регресс на уровне, где применяется контроль.
Что должен вынести QA из этой темы
Сильная security-проверка начинается с понятного запрета и заканчивается проверкой данных и побочных эффектов. Учитывай роли, ownership, жизненный цикл сессии, обработку ввода и ошибки защитных компонентов. Глубокое исследование угроз требует отдельной экспертизы, а повседневный QA уже может закрывать важные риски системными проверками.