OWASP Top 10 — карта важных классов риска web-приложений. Для QA она полезна как способ задать неудобные вопросы к обычной функции: кто может выполнить действие, что произойдёт с недоверенными данными, как система переживёт отказ защитного механизма.
Это документ для повышения осведомлённости, а не полный набор тест-кейсов и не оценка защищённости конкретного продукта. Проверка десяти названий не означает, что все риски найдены. Чтобы превратить карту в работу, нужны модель приложения, требования и конкретные ожидаемые результаты.
Какую редакцию использовать
В этой статье используется OWASP Top 10:2025. На 22 октября 2026 года официальный сайт проекта называет её последней выпущенной редакцией. Указывай год в тестовой документации: номера и состав категорий меняются, поэтому ссылка просто на «A03» без года неоднозначна.
В редакции 2025 расширена тема цепочки поставки ПО, появилась отдельная категория неправильной обработки исключительных условий, а SSRF включён в категорию контроля доступа. Старые материалы 2021 года могут оставаться полезными, но их нумерацию нельзя переносить в новый список без сверки.
A01 и A02: доступ и конфигурация
A01:2025 — нарушение контроля доступа. Для QA это проверки роли, ownership и границ организации: пользователь B не должен скачивать отчёт A, даже зная его ID. Проверь чтение, изменение, удаление и фоновые задания. Одинаковая ошибка может существовать в UI, API и прямой ссылке на файл.
A02:2025 — ошибки конфигурации безопасности. Обрати внимание на debug-режим, лишние endpoints, доступность административных панелей и настройки интеграций. Практическая проверка: релизная сборка не раскрывает stack trace с внутренними данными, а административная функция недоступна публичному пользователю. Настройки тестового и рабочего окружения сравниваются осознанно, а не считаются автоматически одинаковыми.
A03 и A04: поставка ПО и криптография
A03:2025 — сбои цепочки поставки программного обеспечения. Риск шире устаревшей библиотеки: имеет значение происхождение зависимостей, сборки и выпускаемого артефакта. QA может проверить соответствие установленной сборки ожидаемому релизу, наличие результатов проверки зависимостей и воспроизводимость процесса поставки. Глубокий контроль build pipeline выполняется вместе с инженерами безопасности и платформы.
A04:2025 — криптографические сбои. Проверь, где передаются и хранятся чувствительные данные, что попадает в URL и логи, как обрабатывается ошибка защищённого соединения. Наличие HTTPS у главной страницы не доказывает защиту всех интеграций и хранилищ. Требования к алгоритмам и управлению ключами должны исходить из принятой архитектуры безопасности, а не из предположений тестировщика.
A05 и A06: ввод и проектирование
A05:2025 — инъекции. Недоверенные данные не должны превращаться в исполняемые команды или разметку в опасном контексте. Для SQL проверяют параметризацию, для отображения пользовательского текста — обработку в конкретном контексте вывода. Начинай с контролируемых безопасных маркеров на стенде; одно успешное сохранение строки не подтверждает её безопасность во всех местах отображения.
A06:2025 — небезопасное проектирование. Здесь важны ошибки самой модели процесса: например, подтверждение операции без связи с её суммой или возможность бесконтрольного повторения критического действия. QA обсуждает злоупотребления до реализации и проверяет бизнес-инварианты. Исправление одного поля валидации не решит проблему, если весь сценарий допускает нежелательное поведение по своей конструкции.
A07 и A08: личность и целостность
A07:2025 — сбои аутентификации. Проверь жизненный цикл сессии, восстановление доступа, истечение и отзыв credentials, предусмотренное MFA. Например, после завершения восстановления пароля поведение старых сессий должно соответствовать требованиям. Успешный логин проверяет только часть этого жизненного цикла; авторизация на чужой объект остаётся отдельным вопросом.
A08:2025 — сбои целостности программного обеспечения или данных. Приложение не должно доверять артефакту или сообщению без предусмотренной проверки его происхождения и целостности. Полезный QA-сценарий — изменение тестового импортируемого пакета: система отклоняет его там, где требуется подтверждённая целостность, а не продолжает обработку после ошибки проверки.
A09 и A10: обнаружение и исключения
A09:2025 — сбои журналирования событий безопасности и оповещения. Проверь не только наличие записи, но и то, что значимое событие приводит к предусмотренному сигналу и может быть расследовано. Для согласованной серии отказов доступа нужны время, субъект, ресурс и результат без паролей и токенов. Требования определяют, какие события должны вызывать оповещение.
A10:2025 — неправильная обработка исключительных условий. Таймаут, нехватка ресурса или ошибка компонента не должны превращаться в разрешение запрещённой операции. Проверь безопасный исход, состояние данных и ограничение повторов. Возврат HTTP 500 не доказывает безопасность, если задание уже поставлено в очередь и позже исполнится.
Практический пример: создание отчёта
Возьми генерацию отчёта по заказам и привяжи проверки к рискам. Подготовь аккаунты двух тестовых организаций, известный набор заказов и возможность контролируемо вызвать ошибку сервиса прав.
- →A01: пользователь B запрашивает отчёт A; содержимое не раскрывается, новое задание не создаётся.
- →A05: название отчёта содержит безопасные специальные символы; они обрабатываются как данные и корректно отображаются.
- →A09: недопустимая операция оставляет предусмотренное событие с ID проверки без секретов.
- →A10: при таймауте проверки прав экспорт не запускается; после восстановления разрешённый запрос работает.
Измеримый результат — ноль чужих строк в доступном файле, ноль созданных заданий при запрете, ожидаемая запись журнала и корректное восстановление. Одна функция даёт несколько самостоятельных проверок, а связь с категориями помогает объяснить покрытие.
Что должен вынести QA из этой темы
Используй Top 10 как карту вопросов к продукту, затем уточняй требования через ASVS и методы через WSTG. Номер категории не определяет severity отдельного дефекта: важны последствия и условия реализации риска. Фиксируй редакцию, подтверждённые проверки и пробелы покрытия; не превращай знакомство со списком в заявление о полной защищённости.