Введение в OWASP WSTG

$4,99 млн - средняя стоимость утечки данных в мире по IBM Cost of a Data Breach Report 2026. На эту цифру ссылается текущая редакция OWASP WSTG. Атаки с использованием AI зафиксированы более чем в четверти инцидентов и увеличивают среднюю стоимость каждого случая примерно на миллион долларов. Среди уязвимостей веб-приложений — инъекции, ошибки контроля доступа и неучтённые случаи в бизнес-логике. OWASP WSTG (Web Security Testing Guide) помогает систематически проверять такие проблемы: руководство описывает сценарии тестирования безопасности веб-приложений и веб-сервисов.

В этом введении разобраны назначение WSTG, его аудитория, структура и способы работы с руководством. Материал основан на развиваемой редакции (latest) и первоисточниках OWASP. Перевод и редакционные дополнения подготовлены Codeby; их границы указаны в разделе атрибуции. Лицензия перевода и адаптации - CC BY-SA 4.0.

Назначение и границы руководства​

OWASP Web Security Testing Guide (WSTG) - открытое руководство по тестированию безопасности веб-приложений и веб-сервисов. Его развивает сообщество. Описанные методы и техники следует подбирать под модель угроз организации, допустимый уровень риска и процесс разработки. Само по себе прохождение сценариев WSTG не подтверждает соответствие стандартам.

"Безопасность не должна быть чёрной магией или закрытым секретом, доступным лишь немногим." - Eoin Keary

Нажмите, чтобы раскрыть...

Руководство охватывает:

• Традиционные веб-приложения и современные облачные сервисы.
• Настройки инфраструктуры, развёртывание в облаке и контейнеризацию.
• Управление идентификацией, аутентификацию, авторизацию и управление сессиями.
• Валидацию входных данных, кодирование и обработку вывода.
• Обработку ошибок и управление исключениями.
• Криптографические реализации.
• Безопасность бизнес-логики и рабочих процессов.
• Клиентские технологии и безопасность пользовательского интерфейса.
• Безопасность API и точки интеграции.

OWASP WSTG не заменяет: формальные фреймворки управления рисками, такие как NIST Cybersecurity Framework, методологии моделирования угроз, детальные руководства по исправлению уязвимостей (для этого есть OWASP Cheat Sheet Series), полноценный аудит исходного кода (требует white-box доступа и архитектурных знаний, выходящих за рамки тестирования), организационные политики безопасности, а также специализированное тестирование AI/LLM-приложений (см. OWASP AI Testing Guide и OWASP Top 10 for LLM Applications 2026).

Почему OWASP​

Open Worldwide Application Security Project (OWASP) - некоммерческая организация и открытое сообщество специалистов по безопасности ПО. Участники делятся знаниями, создают инструменты и разрабатывают руководства. WSTG объединяет накопленный сообществом опыт тестирования без привязки к продуктам конкретного поставщика.

Руководство доступно всем: изучать его могут специалисты по ИБ, разработчики, QA-инженеры и технические менеджеры. Это позволяет командам, которые создают и выпускают ПО, самостоятельно разбираться в распространённых уязвимостях и способах их проверки.

Тестирование безопасности требует участия разработчиков и тестировщиков наряду со специалистами по AppSec. Понимание того, как проверяют уязвимости, помогает разработчику замечать ошибки в собственном коде.

Предложения и исправления принимаются через issues и pull requests в репозитории GitHub.

Зачем тестировать безопасность веб-приложений​

Тестирование безопасности веб-приложений помогает управлять рисками утечек, сбоев и злоупотреблений. Объём проверок зависит от того, какие данные обрабатывает приложение и какие последствия может вызвать ошибка.

Экономический ущерб​

По данным IBM Cost of a Data Breach Report 2026, средняя стоимость утечки данных в мире составила $4,99 млн (USD), в США - $11,5 млн (USD). Атаки с использованием AI, которые фигурируют более чем в четверти зафиксированных утечек, добавляют в среднем $1 млн (USD) к стоимости каждого инцидента. Утечки также могут вызывать операционные сбои, штрафы и потерю доверия клиентов.

Расширение поверхности атаки​

Проверка внешнего периметра не охватывает все риски приложения. Уязвимости могут затрагивать публичные API и микросервисы, облачную инфраструктуру и serverless-функции, сторонние интеграции и зависимости с открытым исходным кодом, клиентский код в браузерах и мобильных приложениях. Дополнительные риски связаны с цепочкой поставок: скомпрометированными пакетами и подменёнными процессами сборки. В терминах MITRE ATT&CK это означает, что атакующим доступны техники от эксплуатации публично доступных приложений (Exploit Public-Facing Application, T1190, Initial Access) до активного сканирования и поиска уязвимостей (Active Scanning, T1595, Reconnaissance). При планировании тестирования нужно учитывать эти компоненты и связи между ними.

Скорость разработки и проверки безопасности​

AI-инструменты ускоряют написание кода. Если проверки безопасности не успевают за выпуском изменений, в приложении могут накапливаться уязвимости: инъекции, ошибки аутентификации и бизнес-логики.

AI-инструменты применяются и в тестировании: они помогают автоматизировать отдельные задачи поиска уязвимостей. Проверки бизнес-логики, обхода авторизации и рисков, зависящих от контекста, требуют понимания того, как должно работать приложение. Атакующие также используют AI для поиска уязвимостей и адаптации атак.

Автоматическое сканирование подходит для повторяемых проверок. Ручное тестирование и ревью кода дополняют его при поиске ошибок проектирования и бизнес-логики.

Кому предназначено руководство​

Руководство предназначено для:

• Пентестеров и консультантов по безопасности, проводящих оценку приложений.
• Внутренних команд безопасности и QA, тестирующих ПО на всех стадиях разработки.
• Разработчиков и DevSecOps-инженеров, включающих проверки безопасности в CI/CD.
• Архитекторов безопасности, проектирующих стратегии тестирования и программы соответствия.
• Аудиторов и специалистов по соответствию требованиям, проверяющих меры защиты приложений.
• Владельцев продуктов и инженерных менеджеров, определяющих границы проверки, ресурсы и приоритеты тестирования.

Руководство также полезно разработчикам инструментов и организаторам публичных программ bug bounty. Его техники и классификацию можно применять при внутреннем тестировании, стороннем пентесте и координированном раскрытии уязвимостей. Для каждого случая отдельно определяют разрешённые действия, порядок передачи результатов и устранения проблем.

Как устроен документ​

Основные части руководства:

1. Введение — контекст, границы проверки и принципы.
2. Фреймворк тестирования OWASP - проверки на разных этапах жизненного цикла ПО: от определения требований и проектирования до разработки, тестирования, развёртывания и сопровождения. Здесь также рассматриваются непрерывная интеграция, программы bug bounty и работа с AI.
3. Категории тестирования безопасности веб-приложений - конкретные пошаговые процедуры проверки по каждому направлению: аутентификация, валидация ввода, бизнес-логика и другие.
4. Отчётность - форматы отчётов, оценка критичности и представление результатов разным аудиториям.
5. Приложения - инструменты тестирования, рекомендуемая литература, история версий.

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

С чего начать в зависимости от задачи​

Порядок чтения зависит от вашей роли и текущей задачи.

Разработчик. Начните с введения, затем выберите категории, относящиеся к вашему приложению: например, валидацию входных данных, аутентификацию и управление сессиями. В сценариях изучайте способы проверки и раздел "Remediation" с рекомендациями по устранению проблем. Это поможет связать уязвимость с ошибкой в коде.

QA-инженер. Раздел о фреймворке тестирования поможет включить проверки безопасности в существующий процесс. Затем выберите подходящие сценарии и изучите "Test Objectives" и "How to Test": цели и процедуры можно использовать при составлении тестовых кейсов. Чем раньше обнаружена уязвимость, тем меньше изменений может потребоваться для её исправления.

Начинающий тестировщик безопасности. Прочитайте введение и раздел о фреймворке тестирования, затем переходите к категориям проверок. Для первых проектов можно начать со сценариев, связанных с рисками OWASP Top 10, и расширять набор по мере освоения методов и с учётом задач проекта.

Структура сценария проверки​

Каждый сценарий проверки в WSTG построен по единому шаблону:

• Summary (краткое описание) — что проверяется и к каким проблемам относится сценарий.
• Test Objectives (цели проверки) — что нужно установить в ходе теста.
• How to Test (как проверять) — пошаговая процедура с примерами запросов, команд и ожидаемых ответов, включая получение доказательств (PoC) наличия уязвимости.
• Remediation (исправление) — рекомендации по устранению.
• Tools (инструменты) — применимые к этому сценарию.
• References (ссылки) — дополнительные материалы.

Эта структура помогает составить рабочий чек-лист: выбрать подходящие сценарии, определить цели и зафиксировать результаты проверок.

Идентификаторы сценариев и ссылки на версии​

Каждый сценарий имеет идентификатор формата WSTG-<категория>-<номер>, где категория - четырёхбуквенный код (например, INFO - сбор информации, ATHN - аутентификация, INPV - валидация ввода), а номер - двузначное значение от 01 до 99. Пример: WSTG-INFO-02 - второй сценарий проверки в категории сбора информации.

Идентификаторы могут меняться между версиями, поэтому в отчётах, документах и инструментах лучше использовать расширенный формат с версией: WSTG-<версия>-<категория>-<номер>. Пример: WSTG-v42-INFO-02 - второй сценарий сбора информации из версии 4.2.

Если идентификатор указан без версии, предполагается, что он относится к текущему содержимому развиваемой редакции (latest). Поскольку эта редакция обновляется, в отчётах и инструментах следует указывать версию.

Ссылки на сценарии следует формировать с использованием версионных путей, а не stable или latest, содержимое которых со временем изменится. Команда проекта стремится сохранять версионные ссылки неизменными. Пример версионной ссылки:

https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server

Элемент v42 указывает на версию 4.2.

Стабильный релиз и развиваемая редакция​

Обозначение latest на сайте wstg.owasp.org относится к развиваемой редакции. При ссылке на руководство важно отличать её от стабильного релиза.

Неточная формулировка: "Текущая стабильная версия WSTG - latest, доступна на сайте wstg.owasp.org."

С указанием версии: "Последний официальный стабильный релиз - v4.2, соответствующий тегу Release v4.2 на странице релизов GitHub. Ветка latest на сайте wstg.owasp.org/latest/ — это развиваемая редакция, содержимое которой обновляется непрерывно и может отличаться от тегированного релиза. В репозитории также существует тег 20230928-Prerelease - промежуточная сборка между v4.2 и будущей версией. При ссылках из пентест-отчётов и инструментов используйте версионный путь (например, v42), чтобы ссылки оставались неизменными."

Что даёт указание версии. Читатель может открыть ту редакцию сценария, которой пользовался автор отчёта.

Как выбрать ссылку. Номер версии проверяют по официальной странице релизов, а ссылку на сценарий берут из соответствующей редакции.

Например, ссылка на WSTG-INFO-02 без версии со временем может вести к изменённому сценарию. Идентификатор WSTG-v42-INFO-02 сохраняет привязку к версии 4.2 и позволяет проверить, на какую процедуру опирался отчёт.

Как применять руководство​

Набор проверок выбирают с учётом технологий, процессов и структуры организации. Участники команды используют руководство для разных задач:

• Разработчики используют руководство для создания безопасного кода. Подходящие проверки можно включать в юнит-тесты.
• QA-инженеры используют его для расширения набора тестовых кейсов. Раннее обнаружение уязвимостей экономит время и ресурсы.
• Специалисты по безопасности сопоставляют сценарии с другими методами тестирования, чтобы оценить покрытие.
• Менеджеры проектов учитывают ошибки безопасности наряду с другими дефектами кода и архитектуры при планировании работ.

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

Для каждой системы нужен свой набор техник. Прохождение WSTG от начала до конца само по себе не гарантирует полноту проверки: появляются новые уязвимости, а специфические риски приложения могут выходить за пределы руководства.

Автоматизация и ручное тестирование​

DAST (динамическое тестирование), SAST (статический анализ) и SCA (анализ состава ПО) помогают автоматизировать повторяемые проверки и охватить большой объём приложения. Они подходят для поиска типовых проблем и проверки заданных правил. Открытые инструменты вроде ZAP поддерживают эту работу без привязки к конкретному вендору.

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

Результаты сканирования нужно проверять: воспроизводить находки, исключать ложные срабатывания и оценивать последствия. Поэтому автоматизацию сочетают с ручным тестированием и анализом результатов.

Учебный пример: проверка интернет-магазина​

Рассмотрим, как выбрать разделы руководства для проверки интернет-магазина.

Контекст. Команда безопасности получила задание протестировать интернет-магазин перед выпуском новой версии. Согласованы границы проверки: веб-интерфейс покупателя, административная панель и REST API. Проверка проводится по модели "серого ящика": исходный код недоступен, но предоставлены тестовые учётные записи для разных ролей.

Шаг 1. Определите цель. Цель — выявить уязвимости до выпуска версии в эксплуатацию. Аудит соответствия требованиям и полный анализ кода в задачу не входят.

Шаг 2. Выберите маршрут по WSTG. Начните с вводных разделов: назначение руководства (Purpose and Scope), аудитория (Who Should Use This Guide) и устройство документа (How the Guide Is Organized). На знакомство с ними можно отвести 20-30 минут, чтобы разобраться в структуре и классификации сценариев.

Шаг 3. Определите приоритетные категории. В этом примере приоритет получат: управление идентификацией и аутентификацией (WSTG-IDNT, WSTG-ATHN), авторизация (WSTG-ATHZ - проверка IDOR, повышение привилегий), управление сессиями (WSTG-SESS), валидация входных данных (WSTG-INPV - инъекции, XSS), бизнес-логика (WSTG-BUSL - обход процесса оплаты, манипуляция ценами). Для REST API отдельно выбирают сценарии из категории WSTG-APIT: проверки веб-интерфейса не обеспечивают полного покрытия API.

Шаг 4. Спланируйте последовательность. Начните со сбора информации (WSTG-INFO), чтобы определить доступные компоненты и точки входа. Затем переходите к выбранным категориям.

Результат планирования. Определены границы работы, приоритетные категории и порядок проверок.

Следующий этап. По выбранным сценариям нужно выполнить тесты и зафиксировать результаты. Сам по себе план не подтверждает безопасность приложения.

История проекта​

Проект начался в 2003 году, когда Dan Cuthbert стал одним из первых редакторов. В 2005 году проект возглавил Eoin Keary, а руководство перенесли в wiki. С 2013 года Andrew Muller совместно с Matteo Meucci руководил проектом до 2018/2019. Выпусками после v4 и подготовкой v5 руководят Rick Mitchell и Elie Saad.

Хронология выпусков по данным Appendix A и страницы релизов GitHub:

• Декабрь 2004 - The OWASP Testing Guide, Version 1.0
• Июль 2004 - OWASP Web Application Penetration Checklist, Version 1.1
• Декабрь 2006 - OWASP Testing Guide, Version 2.0
• Сентябрь 2008 - OWASP Testing Guide, Version 3.0
• Сентябрь 2014 - OWASP Testing Guide, Version 4.0
• Апрель 2020 - OWASP Testing Guide, Version 4.1
• Version 4.2 - последний тегированный стабильный релиз на GitHub (Appendix A оригинала не фиксирует v4.2 в хронологии, однако тег Release v4.2 присутствует в репозитории).

За более чем 20 лет руководство выросло из чек-листа в набор методик и сценариев проверки. Оно охватывает, в частности, облачные приложения, API и WebSocket.

Обратная связь и связанные проекты​

Обратная связь​

Если вы обнаружили ошибку, устаревшую ссылку или недостающий сценарий, можно открыть issue или предложить исправление через pull request в репозитории WSTG на GitHub. Полезно приложить условия воспроизведения и описать, что удалось проверить, а где процедура не дала ожидаемого результата.

Опыт применения сценариев помогает поддерживать руководство в актуальном состоянии. При этом WSTG не претендует на исчерпывающий охват всех проблем безопасности.

Связанные проекты OWASP​

Другие проекты OWASP дополняют WSTG:

OWASP ASVS (Application Security Verification Standard) - каталог функциональных требований безопасности, определяющий базовый набор "что проверять". Актуальная стабильная версия - v5.0 (выпущена в мае 2025 года), включает современные облачные архитектуры. Источник: owasp.org/www-project-application-security-verification-standard.

OWASP Top 10 (2025) и OWASP API Security Top 10 (2023) - составленные сообществом перечни наиболее критичных рисков для веб-приложений и API. Помогают расставлять приоритеты тестирования. Источники: owasp.org/Top10, owasp.org/API-Security.

OWASP Top 10 for LLM Applications 2026 и OWASP AI Testing Guide (v1, опубликован 26 ноября 2025 года) — специализированное руководство по тестированию AI/LLM-приложений: prompt injection, галлюцинации, отравление моделей. Источники: genai.owasp.org, owasp.org/www-project-ai-testing-guide.

OWASP AI Exchange - база знаний по управлению безопасностью AI, оценке рисков и моделированию угроз для AI-систем. Источник: owaspai.org.

OWASP Mobile Application Security (MASVS/MASTG) - стандарт верификации безопасности и руководство по тестированию для iOS- и Android-приложений. Источник: mas.owasp.org.

OWASP OpenCRE (Open Common Requirements Enumeration) - интерактивная платформа, которая связывает требования безопасности, методы тестирования и меры защиты из разных стандартов и классификаций (ASVS, NIST, ISO, CWE). Она помогает сопоставлять сценарии WSTG с требованиями других документов. Источник: opencre.org.

OWASP SAMM (Software Assurance Maturity Model) - фреймворк для оценки и улучшения практик безопасности приложений. Определяет пять бизнес-функций и пятнадцать практик безопасности. Источник: owaspsamm.org.

OWASP Threat Dragon и pytm (Pythonic Threat Modeling) - инструменты для создания и документирования моделей угроз. Источники: owasp.org/www-project-threat-dragon, owasp.org/www-project-pytm.

OWASP Cheat Sheet Series - лаконичное руководство по конкретным темам безопасности (аутентификация, криптография, API) с примерами кода. Источник: cheatsheetseries.owasp.org.

Лицензия, атрибуция и границы перевода​

Лицензия и авторские права​

Copyright (c) 2026 The OWASP Foundation. Оригинальный документ выпущен под лицензией Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). Этот перевод и редакционная актуализация также распространяются на условиях CC BY-SA 4.0.

Текущие руководители проекта WSTG: Elie Saad и Rick Mitchell. Ядро команды: Rejah Rehim, Victoria Drake. В создании руководства участвовали десятки авторов, рецензентов, дизайнеров и редакторов. Полный список доступен на официальной странице About.

Open Worldwide Application Security Project и OWASP — зарегистрированные товарные знаки OWASP Foundation, Inc. Связаться с OWASP Foundation можно через официальный сайт.

Границы перевода и редакционной актуализации​

Codeby подготовил перевод фрагментов OWASP WSTG и редакционные дополнения. Состав материала и отличия от оригинала:

• Переведены разделы 0 (Foreword), 1 (About), 2.1-2.3, 2.5-2.8 (Introduction) и Appendix A (History) по состоянию развиваемой редакции (latest) на октябрь 2026 года.
• Раздел 2.4 (Core Principles of Effective Security Testing) не включён - он относится к отдельной теме.
• Добавлены редакционные блоки: маршруты чтения по ролям, учебные примеры планирования проверки и различий между развиваемой редакцией и стабильным релизом. Эти блоки не являются частью оригинального текста WSTG.
• Скорректированы названия проектов: LLM Top 10 указан как "OWASP Top 10 for LLM Applications 2026" (текущее официальное название), AI Testing Guide - с указанием выхода v1 (26 ноября 2025). Обновления основаны на верификации официальных страниц проектов.
• Уточнена информация о версиях: v4.2 идентифицирована как последний тегированный стабильный релиз на основании страницы релизов GitHub, хотя Appendix A оригинала не упоминает v4.2 в хронологии.

Исходные URL первоисточников:


Дата снимка первоисточников: 17 октября 2026 года.

WSTG удобно использовать при составлении плана проверки: сопоставить категории с устройством приложения и выбрать подходящие сценарии. OWASP Top 10 помогает определить приоритетные риски, а WSTG описывает методы их проверки. В отчёте стоит указывать версию руководства, использованные сценарии и полученные доказательства.

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