OWASP Top 10: главные риски безопасности веб-приложений

Действующая редакция — OWASP Top 10:2025, официально выпущенная в январе 2026 года после анонса на конференции OWASP Global AppSec в ноябре 2025 года; сам OWASP Top 10 — регулярно обновляемый список десяти самых критичных категорий риска безопасности веб-приложений, который публикует некоммерческая организация OWASP (Open Worldwide Application Security Project).

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

OWASP — некоммерческий фонд, работающий с 2001 года; в 2023 году переименован в Open Worldwide Application Security Project (ранее — Open Web Application Security Project), но аббревиатура OWASP при этом сохранилась неизменной. Фонд существует на пожертвования компаний-спонсоров, членские взносы и труд волонтёров — сообщества разработчиков, пентестеров и исследователей, включая локальные отделения (chapters) в десятках стран.

Помимо Top 10 для веб-приложений, OWASP публикует ASVS (Application Security Verification Standard) — детализированный чек-лист для аудита, Testing Guide — методику тестирования, Cheat Sheet Series — практические памятки по конкретным темам, а также отдельные списки рисков для других типов приложений — OWASP API Security Top 10 для API и OWASP Top 10 for LLM Applications для приложений на основе больших языковых моделей.

Первая версия списка вышла в 2003 году. С тех пор она обновлялась в 2004, 2007, 2010, 2013, 2017, 2021 и 2025 годах — действующей редакцией стала OWASP Top 10:2025, а предыдущей теперь считается редакция 2021 года, опубликованная в сентябре 2021 года. При использовании термина в тендерной или проектной документации разумно явно указывать редакцию (2025), поскольку состав и нумерация категорий заметно отличаются от версии 2021 года.

OWASP Top 10 нужен, чтобы дать команде разработки, тестирования и безопасности общий язык и порядок приоритетов при ограниченном времени и бюджете — вместо попытки закрыть сотни отдельных типов уязвимостей одновременно, список указывает на десять категорий, которые на практике встречаются чаще и наносят наибольший ущерб. Это не техническое задание «сделай именно так», а awareness document — документ повышения осведомлённости, задача которого — привлечь внимание к приоритетам, а не заменить полноценный процесс безопасной разработки.

На практике список используют в нескольких сценариях:

• Обучение разработчиков. Базовый ориентир для тренингов по безопасному кодированию — какие классы ошибок разбирать в первую очередь.
• Требования в тендерах и договорах. Формулировка «приложение должно быть протестировано на соответствие OWASP Top 10» — частое требование в закупочной документации и договорах на разработку или пентест.
• Структура отчётов о тестировании на проникновение. Найденные уязвимости часто классифицируют по категориям OWASP Top 10 — это упрощает сравнение отчётов разных исполнителей и приоритизацию исправлений.
• Таксономия сканеров и средств защиты. Средства статического и динамического анализа кода (SAST/DAST) и WAF используют категории OWASP как один из классификаторов обнаруженных рисков.
• Точка входа в более полные стандарты. Для формальной и детализированной проверки соответствия OWASP предлагает ASVS — три уровня строгости проверки, где Top 10 служит упрощённым входом в тему, а не заменяет полноценный аудит.

У списка есть ограничение: он не покрывает все возможные уязвимости и не заменяет специфичные для отрасли или архитектуры требования — например, для финансовых организаций в России параллельно действуют собственные требования к разработке (раздел ниже про РБПО и ГОСТ Р 56939).

Действующая редакция OWASP Top 10:2025 включает десять категорий риска с кодами от A01 до A10 — от нарушения контроля доступа, которое сохранило первое место и по пути поглотило прежнюю отдельную категорию SSRF, до двух новых категорий — сбоев цепочки поставок ПО и некорректной обработки исключительных ситуаций. Таблица ниже — суть каждой категории одной фразой и то, что изменилось по сравнению с редакцией 2021 года.

↔ таблицу можно прокрутить вбок

Главные структурные изменения редакции 2025 года — две новые категории и одно поглощение. A03 Software Supply Chain Failures — не просто переименование прежней «Vulnerable and Outdated Components» (A06:2021), а более широкая категория: она охватывает риски всей цепочки поставки программного обеспечения, включая CI/CD-конвейеры и репозитории пакетов, а не только устаревшие библиотеки.

A10 Mishandling of Exceptional Conditions — категория, которой не было ни в одной из прежних редакций. При этом отдельная категория SSRF (Server-Side Request Forgery), впервые появившаяся в редакции 2021 года как A10, в 2025 году отдельно не выделена — соответствующий тип атаки теперь описывается в рамках более широкой категории A01 Broken Access Control.

Категория A05 Injection при этом остаётся одной из самых опасных по последствиям: её главный представитель — SQL-инъекция, атака на приложения с базой данных, которая по отдельности разобрана на SecRadar подробнее, чем позволяет формат одной строки таблицы.

Точные показатели распространённости (occurrence rate) по каждой категории редакции 2025 года OWASP публикует в собственной методологии подсчёта; переносить сюда числовые пороги без прямой сверки с первоисточником SecRadar не стал — для справки: в редакции 2021 года OWASP указывал 94% для категории A01 Broken Access Control, но этот показатель относился именно к составу и выборке 2021 года и не переносится на редакцию 2025 автоматически.

Защита от рисков OWASP Top 10 разложена по трём фазам жизненного цикла приложения — разработка, тестирование перед релизом и эксплуатация, — и ни одна фаза не заменяет остальные: инструмент периметра не устраняет ошибку в архитектуре, а безопасный код не отменяет необходимость мониторинга в проде.

Независимо от того, какие инструменты уже внедрены, периодическая независимая проверка нужна как контроль качества всей цепочки: пентест — тестирование на проникновение, где эксперт пытается воспроизвести реальную атаку по каждой из категорий OWASP Top 10 и подтверждает или опровергает эффективность выстроенной защиты.

OWASP Top 10 не является российским нормативным документом и не упоминается в ГОСТ Р 56939 напрямую как обязательная норма — это международный отраслевой ориентир, тогда как российская разработка безопасного программного обеспечения (РБПО) для субъектов КИИ и государственных информационных систем опирается на собственную нормативную базу — прежде всего ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» и методические документы ФСТЭК России.

На практике оба контура пересекаются не по букве закона, а по содержанию проверок. РБПО по ГОСТ Р 56939 требует статического и динамического анализа кода на каждом этапе разработки, а инструменты такого анализа — SAST, DAST, средства фаззинга — на практике классифицируют находки в том числе по категориям OWASP Top 10, потому что это общепринятый в отрасли язык описания уязвимостей, а не потому, что ГОСТ прямо ссылается на OWASP.

Категория A03 Software Supply Chain Failures редакции 2025 года содержательно близка к требованиям РБПО об анализе состава и происхождения компонентов ПО (SBOM), хотя формулировки и методология у ГОСТа и OWASP разные. Формальное соответствие ГОСТ Р 56939 и прохождение оценки у ФСТЭК не подменяет проверку по OWASP Top 10 и наоборот — это два разных, хотя и содержательно смежных, трека: подробный разбор состава требований, кого касается РБПО и как проходит сертификация — на странице «РБПО и ГОСТ Р 56939».

Для организации на практике это означает: соответствие OWASP Top 10 стоит использовать как рабочий чек-лист безопасности приложения независимо от отраслевой принадлежности, а официальные обязательства по РБПО — сверять отдельно по ГОСТ Р 56939 и актуальным методическим документам ФСТЭК, если организация подпадает под их требования — субъект КИИ, оператор значимого объекта, разработчик ПО для ГИС.