OWASP Топ-10 (2025)

OWASP Top 10 - это стандартный информационный документ для разработчиков и безопасности веб-приложений. Он представляет собой широкий консенсус в отношении наиболее критических рисков безопасности веб-приложений. Он признан разработчиками во всем мире как первый шаг к более безопасному кодированию.

Что изменилось в Топ-10 за 2025 год

В Топ-10 за 2025 год появились две новые категории, а одна была объединена. OWASP постарались сохранить наш фокус на первопричинах, а не на симптомах, насколько это возможно. Учитывая сложность разработки программного обеспечения и его безопасности, создать десять категорий без какого-либо уровня пересечения практически невозможно.

Соответствие категорий

A01:2025 - Неконтролируемый доступ (Broken Access Control) сохраняет свою позицию на №1 как наиболее серьезный риск для безопасности приложений; предоставленные данные указывают, что в среднем 3,73% протестированных приложений имели одну или несколько из 40 перечисленных стандартных уязвимостей (CWE) в этой категории. Как показано пунктирной линией на рисунке выше, подделка запроса на стороне сервера (SSRF) была включена в эту категорию.
A02:2025 - Небезопасная конфигурация (Security Misconfiguration) поднялась с 5-го места в 2021 году на 2-е в 2025. Неверные конфигурации стали более распространенными в данных за этот цикл. 3,00% протестированных приложений имели одну или несколько из 16 CWE в этой категории. Это неудивительно, так как в разработке программного обеспечения продолжает увеличиваться объем поведения приложения, основанного на конфигурациях.
A03:2025 - Сбои в цепочке поставок ПО (Software Supply Chain Failures) является расширением категории A06:2021 - Уязвимые и устаревшие компоненты (Vulnerable and Outdated Components), чтобы включить более широкий спектр компрометаций, происходящих внутри или через всю экосистему зависимостей ПО, систем сборки и инфраструктуры распространения. Эта категория получила подавляющее большинство голосов как главная проблема в опросе сообщества. В этой категории 5 CWE, и она слабо представлена в собранных данных, но мы полагаем, что это связано со сложностями тестирования, и надеемся, что тестирование в этой области улучшится. У этой категории наименьшее количество случаев в данных, но при этом самые высокие средние баллы эксплуатации и воздействия по CVE.
A04:2025 - Сбои криптографии (Cryptographic Failures) опускается на две позиции со 2-го на 4-е место в рейтинге. Предоставленные данные указывают, что в среднем 3,80% приложений имеют одну или несколько из 32 CWE в этой категории. Эта категория часто приводит к раскрытию конфиденциальных данных или компрометации системы.
A05:2025 - Внедрение (Injection) опускается на две позиции с 3-го на 5-е место в рейтинге, сохраняя свою позицию относительно "Сбоев криптографии" и "Небезопасного проектирования". "Внедрение" — одна из наиболее часто тестируемых категорий с наибольшим количеством CVE, связанных с 38 CWE в этой категории. Она включает в себя ряд проблем, от межсайтового скриптинга (XSS - высокая частота/низкая тяжесть последствий) до уязвимостей внедрения SQL-кода (низкая частота/высокая тяжесть последствий).
A06:2025 - Небезопасное проектирование (Insecure Design) опускается на две позиции с 4-го на 6-е место, так как "Небезопасная конфигурация" и "Сбои в цепочке поставок ПО" обогнали его. Эта категория была введена в 2021 году, и мы заметили значительные улучшения в отрасли, связанные с моделированием угроз и повышенным вниманием к безопасному проектированию.
A07:2025 - Сбои аутентификации (Authentication Failures) сохраняет свою позицию на №7 с небольшим изменением названия (ранее "Сбои идентификации и аутентификации"), чтобы точнее отразить 36 CWE в этой категории. Эта категория остается важной, но более широкое использование стандартизированных фреймворков для аутентификации, по-видимому, оказывает положительный эффект на частоту случаев сбоев аутентификации.
A08:2025 - Сбои целостности ПО или данных (Software or Data Integrity Failures) остается на 8-м месте в списке. Эта категория сфокусирована на неспособности поддерживать границы доверия и проверять целостность программного обеспечения, кода и артефактов данных на более низком уровне, чем "Сбои в цепочке поставок ПО".
A09:2025 - Сбои журналирования и оповещения (Logging & Alerting Failures) сохраняет свою позицию на №9. Название этой категории немного изменено (ранее "Сбои журналирования и мониторинга безопасности"), чтобы подчеркнуть важность функциональности оповещений, необходимой для принятия соответствующих мер по соответствующим событиям в журналах. Отличное журналирование без оповещений имеет минимальную ценность для выявления инцидентов безопасности. Эта категория всегда будет недостаточно представлена в данных, и она снова была включена в список по результатам голосования участников опроса сообщества.
A10:2025 - Некорректная обработка исключительных ситуаций (Mishandling of Exceptional Conditions) - это новая категория для 2025 года. Она содержит 24 CWE, фокусирующихся на некорректной обработке ошибок, логических ошибках, небезопасном поведении при отказах ("fail open") и других связанных сценариях, проистекающих из аномальных условий, с которыми могут столкнуться системы.

Список OWASP TOP 10 - 2025

A01:2025 Неконтролируемый доступ (Broken Access Control)

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

Нарушение принципа наименьших привилегий, широко известного как "запрещено по умолчанию", когда доступ должен предоставляться только для определенных возможностей, ролей или пользователей, но доступен для всех.
Обход проверок контроля доступа путем изменения URL (подмена параметров или принудительный просмотр), внутреннего состояния приложения или HTML-страницы, либо с использованием инструмента атаки, который изменяет запросы к API.
Разрешение на просмотр или редактирование чужой учетной записи путем предоставления ее уникального идентификатора (небезопасные прямые ссылки на объекты).
Доступный API с отсутствующим контролем доступа для методов POST, PUT и DELETE.
Повышение привилегий. Действия от имени пользователя без входа в систему или действия в качестве администратора при входе в систему под обычным пользователем.
Манипуляция метаданными, например, повторное использование или подмена токена контроля доступа JSON Web Token (JWT), манипуляция файлом cookie или скрытым полем для повышения привилегий или злоупотребление инвалидацией JWT.
Неверная конфигурация CORS, позволяющая доступ к API с неавторизованных или ненадежных источников.
Принудительный просмотр (угадывание URL) аутентифицированных страниц в качестве неаутентифицированного пользователя или привилегированных страниц в качестве стандартного пользователя.

A02:2025 Небезопасная конфигурация (Security Misconfiguration)

Небезопасная конфигурация - это ситуация, когда система, приложение или облачная служба настроены неправильно с точки зрения безопасности, что создает уязвимости.

Приложение может быть уязвимым, если:

В какой-либо части стека приложения отсутствует соответствующее усиление безопасности или неправильно настроены разрешения в облачных службах.
Включены или установлены ненужные функции (например, ненужные порты, службы, страницы, учетные записи, инструменты тестирования или привилегии).
Учетные записи по умолчанию и их пароли по-прежнему активны и не изменены.
Отсутствует централизованная настройка для перехвата избыточных сообщений об ошибках. Обработка ошибок раскрывает пользователям трассировку стека или другие излишне информативные сообщения.
Для обновленных систем последние функции безопасности отключены или не настроены безопасным образом.
Чрезмерный приоритет обратной совместимости приводит к небезопасной конфигурации.
Параметры безопасности на серверах приложений, в фреймворках (например, Struts, Spring, ASP.NET), библиотеках, базах данных и т.д. не установлены в безопасные значения.
Сервер не отправляет заголовки или директивы безопасности, либо они не установлены в безопасные значения.

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

A03:2025 Сбои в цепочке поставок ПО (Software Supply Chain Failures)

Сбои в цепочке поставок ПО - это нарушения или иные компрометации в процессе сборки, распространения или обновления программного обеспечения. Они часто вызваны уязвимостями или злонамеренными изменениями в стороннем коде, инструментах или других зависимостях, которые использует система.

Вы, вероятно, уязвимы, если:

Вы не отслеживаете тщательно версии всех используемых компонентов (как на стороне клиента, так и на стороне сервера). Это включает компоненты, которые вы используете напрямую, а также вложенные (транзитивные) зависимости.
Программное обеспечение является уязвимым, неподдерживаемым или устаревшим. Это включает ОС, веб-сервер/сервер приложений, СУБД, приложения, API и все компоненты, среды выполнения и библиотеки.
Вы не выполняете регулярное сканирование на наличие уязвимостей и не подписаны на бюллетени безопасности, связанные с используемыми компонентами.
У вас нет процесса управления изменениями или отслеживания изменений в вашей цепочке поставок, включая отслеживание IDE, их расширений и обновлений, изменений в репозитории кода вашей организации, песочницах, репозиториях образов и библиотек, процессах создания и хранения артефактов и т.д. Каждая часть вашей цепочки поставок должна быть задокументирована, особенно изменения.
Вы не усилили безопасность каждой части вашей цепочки поставок, с особым вниманием к контролю доступа и применению принципа наименьших привилегий.
В системах вашей цепочки поставок нет разделения обязанностей. Ни один человек не должен иметь возможность написать код и провести его полностью до продуктивной среды без надзора другого человека.
Разработчикам, DevOps-инженерам или специалистам по инфраструктуре разрешено загружать и использовать компоненты из ненадежных источников для использования в продуктивной среде.
Вы не исправляете и не обновляете базовую платформу, фреймворки и зависимости на основе оценки рисков и своевременно. Это часто происходит в средах, где исправление — это ежемесячная или ежеквартальная задача в рамках управления изменениями, что оставляет организации открытыми для дней или месяцев излишнего воздействия угроз до устранения уязвимостей.
Разработчики не тестируют совместимость обновленных или исправленных библиотек.
Вы не обеспечили безопасную конфигурацию каждой части вашей системы (см. A02:2025 — Небезопасная конфигурация).
У вас сложный CI/CD-конвейер, который использует множество компонентов, но имеет более слабую безопасность, чем остальные части вашего приложения.

A04:2025 Сбои криптографии (Cryptographic Failures)

Вообще говоря, все передаваемые данные должны быть зашифрованы на транспортном уровне (уровень 4 модели OSI). Прежние препятствия, такие как производительность ЦП и управление закрытыми ключами/сертификатами, теперь решены благодаря наличию в процессорах инструкций, разработанных для ускорения шифрования (например, поддержка AES), а управление закрытыми ключами и сертификатами упрощено благодаря таким сервисам, как LetsEncrypt.org, а крупные облачные провайдеры предлагают еще более тесно интегрированные службы управления сертификатами для своих платформ.

Помимо защиты транспортного уровня, важно определить, какие данные необходимо шифровать при хранении, а какие требуют дополнительного шифрования при передаче (на уровне приложений, уровень 7 OSI). Например, пароли, номера кредитных карт, медицинские записи, личная информация и коммерческие тайны требуют дополнительной защиты, особенно если эти данные подпадают под действие законов о конфиденциальности, таких как Общий регламент по защите данных (GDPR) ЕС, или нормативных актов, таких как стандарт безопасности данных индустрии платежных карт (PCI DSS). Для всех таких данных:

Используются ли по умолчанию или в старом коде устаревшие или слабые криптографические алгоритмы или протоколы?
Используются ли ключи шифрования по умолчанию, генерируются ли слабые ключи, происходит ли повторное использование ключей или отсутствует надлежащее управление ключами и их смена?
Проверяются ли ключи шифрования в репозиториях исходного кода?
Не применяется ли принудительное шифрование, например, отсутствуют ли HTTP-заголовки (браузера) директивы безопасности?
Правильно ли проверяется полученный сертификат сервера и цепочка доверия?
Игнорируются ли, повторно используются или ненадлежащим образом генерируются векторы инициализации для данного режима шифрования? Используются ли небезопасные режимы, такие как ECB? Применяется ли шифрование там, где более уместно аутентифицированное шифрование?
Используются ли пароли в качестве криптографических ключей при отсутствии функции формирования ключа на основе пароля?
Используется ли для криптографических целей генератор случайных чисел, не предназначенный для удовлетворения криптографических требований? Даже если выбран правильный метод, требует ли он, чтобы разработчик задал начальное значение (seed), и если нет, не перезаписал ли разработчик встроенную функцию сильной инициализации значением с недостаточной энтропией/непредсказуемостью?
Используются ли устаревшие хеш-функции, такие как MD5 или SHA1, или применяются ли некриптографические хеш-функции там, где необходимы криптографические?
Используются ли устаревшие методы криптографического дополнения (padding), такие как PKCS #1 v1.5?
Можно ли эксплуатировать криптографические сообщения об ошибках или информацию с побочных каналов, например, в виде атак оракула по дополнению (padding oracle attacks)?
Можно ли понизить версию криптографического алгоритма или обойти его?

A05:2025 Инъекции (Injection)

Уязвимость инъекции - это недостаток системы, который позволяет злоумышленнику вставить вредоносный код или команды (такие как SQL-код или shell-команды) в поля ввода программы, обманывая систему и заставляя ее выполнить этот код или команды, как если бы они были частью системы. Это может привести к поистине тяжелым последствиям.

Приложение уязвимо для атаки, когда:

Предоставленные пользователем данные не проверяются, не фильтруются и не санируются приложением.
Динамические запросы или непараметризованные вызовы без экранирования, учитывающего контекст, используются напрямую в интерпретаторе.
Несанированные данные используются в параметрах поиска ORM (Object-Relational Mapping) для извлечения дополнительных, чувствительных записей.
Потенциально враждебные данные используются напрямую или объединяются (конкатенируются). SQL-запрос или команда содержит структуру и вредоносные данные в динамических запросах, командах или хранимых процедурах.
Некоторые из наиболее распространенных видов инъекций - это SQL, NoSQL, инъекции команд ОС, ORM, LDAP, а также инъекции в языки выражений (EL) или библиотеки обхода графов объектов (OGNL). Концепция идентична для всех интерпретаторов.

Обнаружение лучше всего достигается комбинацией анализа исходного кода и автоматизированного тестирования (включая фаззинг) всех параметров, заголовков, URL, кук, а также данных в форматах JSON, SOAP и XML. Внедрение инструментов статического (SAST), динамического (DAST) и интерактивного (IAST) тестирования безопасности приложений в CI/CD-конвейер также может помочь выявить недостатки инъекций перед развертыванием в продуктивной среде.

A06:2025 Ненадёжная архитектура (Insecure Design)

Ненадёжная архитектура - это обширная категория, представляющая различные недостатки, выраженные как «отсутствие или неэффективность проектирования средств контроля». Ненадёжная архитектура не является источником всех остальных категорий риска из Топ-10. Обратите внимание, что существует разница между ненадёжной архитектурой и ненадёжной реализацией. Мы различаем архитектурные недочёты и дефекты реализации неслучайно: у них разные первопричины, они возникают в разное время в процессе разработки и требуют разных способов устранения. Защищённая архитектура всё же может иметь дефекты реализации, ведущие к уязвимостям, которые могут быть использованы. Ненадёжную архитектуру нельзя исправить безупречной реализацией, поскольку необходимые средства защиты никогда не создавались для отражения конкретных атак. Один из факторов, способствующих ненадёжной архитектуре, — это отсутствие профилирования бизнес-рисков, присущего разрабатываемому программному обеспечению или системе, и, как следствие, неспособность определить, какой уровень проектирования безопасности требуется.

Три ключевых составляющих защищённой архитектуры:

Сбор требований и управление ресурсами
Создание защищённой архитектуры
Наличие жизненного цикла безопасной разработки

A07:2025 Сбои аутентификации (Authentication Failures)

Данная уязвимость присутствует, когда злоумышленник может обмануть систему, заставив её признать недействительного или неправильного пользователя легитимным. Слабые места в аутентификации могут быть, если приложение:

Позволяет автоматизированные атаки, такие как подбор учетных данных (credential stuffing), когда у злоумышленника есть скомпрометированный список действительных имен пользователей и паролей. В последнее время такие атаки расширились и включают гибридные атаки на пароли (также известные как атаки распылением паролей - password spray attacks), когда злоумышленник использует вариации или инкрементальные изменения утекших учетных данных для получения доступа, например, перебирая Password1!, Password2!, Password3! и так далее.
Позволяет атаки грубой силы (brute force) или другие автоматизированные, скриптовые атаки, которые не блокируются быстро.
Допускает использование паролей по умолчанию, слабых или общеизвестных паролей, таких как "Password1" или имя пользователя "admin" с паролем "admin".
Позволяет пользователям создавать новые учетные записи с уже известными, скомпрометированными учетными данными.
Позволяет использование слабых или неэффективных процессов восстановления учетных данных и забытых паролей, таких как «вопросы для восстановления» (knowledge-based answers), которые не могут быть сделаны безопасными.
Использует хранилища данных с паролями в открытом тексте, зашифрованными или слабо хешированными (см. A04:2025 – Сбои криптографии).
Имеет отсутствующую или неэффективную многофакторную аутентификацию (MFA).
Позволяет использование слабых или неэффективных обходных механизмов, если многофакторная аутентификация недоступна.
Раскрывает идентификатор сессии в URL, скрытом поле или другом незащищенном месте, доступном клиенту.
Повторно использует тот же идентификатор сессии после успешного входа в систему.
Не корректно аннулирует пользовательские сессии или токены аутентификации (в основном токены единого входа - Single Sign-On (SSO)) при выходе из системы или после периода бездействия.

A08:2025 Сбои целостности ПО или данных (Software or Data Integrity Failures)

Сбои целостности программного обеспечения и данных связаны с кодом и инфраструктурой, которые не защищают от ситуаций, когда недопустимый или ненадёжный код или данные рассматриваются как доверенные и действительные. Примером этого является случай, когда приложение полагается на плагины, библиотеки или модули из ненадёжных источников, репозиториев и сетей доставки контента (CDN). Небезопасный CI/CD-конвейер, который не потребляет и не предоставляет проверки целостности ПО, может создать потенциальную возможность для несанкционированного доступа, попадания небезопасного или вредоносного кода или компрометации системы. Другой пример - это CI/CD, который извлекает код или артефакты из ненадёжных мест и/или не проверяет их перед использованием (путём проверки подписи или аналогичного механизма). Наконец, многие приложения теперь включают функцию автоматического обновления, когда обновления загружаются без достаточной проверки целостности и применяются к ранее доверенному приложению. Злоумышленники могут потенциально загружать собственные обновления для распространения и запуска во всех инсталляциях. Другой пример - когда объекты или данные кодируются или сериализуются в структуру, которую злоумышленник может видеть и изменять, что делает их уязвимыми для небезопасной десериализации.

A09:2025 Сбои журналирования и оповещения (Logging & Alerting Failures)

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

Регистрируемые события (Auditable events), такие как входы в систему, неудачные попытки входа и транзакции с высокой ценностью, не регистрируются или регистрируются непоследовательно (например, регистрируются только успешные входы, но не неудачные попытки).
Предупреждения и ошибки не генерируют журнальных сообщений, либо сообщения неадекватны или неясны.
Целостность журналов не защищена должным образом от несанкционированного изменения.
Журналы приложений и API не отслеживаются на предмет подозрительной активности.
Журналы хранятся только локально и не имеют надлежащего резервного копирования.
Отсутствуют или неэффективны соответствующие пороги срабатывания оповещений и процессы эскалации реагирования. Оповещения не поступают или не проверяются в разумные сроки.
Тестирование на проникновение и проверки с помощью инструментов динамического тестирования безопасности приложений (DAST), таких как Burp или ZAP, не вызывают срабатывания оповещений.
Приложение не может обнаруживать, эскалировать или сигнализировать об активных атаках в реальном времени или почти в реальном времени.
Вы уязвимы к утечке конфиденциальной информации из-за того, что события журналирования и оповещения видны пользователю или злоумышленнику (см. A01:2025 – Неконтролируемый доступ), или из-за регистрации конфиденциальной информации, которая не должна попадать в журналы (например, PII или PHI).
Вы уязвимы для инъекций или атак на системы журналирования или мониторинга, если данные журналов не корректно кодированы.
В приложении отсутствует или некорректно обрабатываются ошибки и другие исключительные ситуации, так что система не знает о возникновении ошибки и, следовательно, не может зарегистрировать проблему.
Отсутствуют или устарели соответствующие «сценарии использования» (use cases) для выдачи оповещений, позволяющие распознать особую ситуацию.
Слишком большое количество ложных срабатываний делает невозможным отличить важные оповещения от неважных, в результате чего они распознаются слишком поздно или вообще не распознаются (физическая перегрузка команды SOC).
Обнаруженные оповещения не могут быть корректно обработаны, потому что плейбук (playbook) для сценария использования неполный, устаревший или отсутствует.

A10:2025 Некорректная обработка исключительных ситуаций (Mishandling of Exceptional Conditions)

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

Исключительные ситуации могут быть вызваны отсутствием, недостаточной или неполной проверкой входных данных; обработкой ошибок на высоком уровне, а не в функциях, где они возникают; непредвиденными состояниями среды, такими как проблемы с памятью, привилегиями или сетью; непоследовательной обработкой исключений; или же исключениями, которые вообще не обрабатываются, что позволяет системе перейти в неизвестное и непредсказуемое состояние. Каждый раз, когда приложение не уверено в своей следующей инструкции, это означает, что исключительная ситуация была обработана некорректно. Труднообнаруживаемые ошибки и исключения могут в течение длительного времени угрожать безопасности всего приложения.

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

Логические ошибки (logic bugs)
Переполнения (overflows)
Состояния гонки (race conditions)
Мошеннические транзакции (fraudulent transactions)
Проблемы с памятью, состоянием, ресурсами, временем, аутентификацией и авторизацией

Эти типы уязвимостей могут негативно повлиять на конфиденциальность, доступность и/или целостность системы или её данных. Злоумышленники манипулируют flawed обработкой ошибок приложения, чтобы использовать эту уязвимость.