OWASP Top 10 2025: как меняется приоритет угроз и почему безопасный код уже не хватает
-------------------------------------------------------------------------------
OWASP Top 10 традиционно воспринимают как "шпаргалку" по главным рискам для веб-приложений. Это не просто рейтинг популярных уязвимостей, а ориентир, по которому команды разработки, архитекторы и специалисты по ИБ выстраивают приоритеты: что закрывать в первую очередь, куда направлять усилия тестирования и какие практики безопасности внедрять в процесс.
С 2021 года ландшафт атак сильно изменился. Массовый переход в облако, активное использование сторонних библиотек и сервисов, распространение DevOps и автоматизации сборки - всё это сделало уязвимости более "распределёнными" и сложными. В обновлённой версии OWASP Top 10:2025 это хорошо заметно: часть категорий уточнена, переработаны формулировки, а в список вошли новые риски, связанные с цепочкой поставок и обработкой исключительных ситуаций.
Что нового в OWASP Top 10:2025
По сравнению с редакцией 2021 года список не был переписан с нуля, но приоритеты заметно сместились. Большинство категорий сохранились, однако:
* переработан акцент внутри некоторых пунктов (например, в логировании и аутентификации);
* объединены близкие по сути риски (как в случае SSRF и контроля доступа);
* добавлены две новые категории:
* A03:2025 Software Supply Chain Failures - проблемы в цепочке поставок ПО;
* A10:2025 Mishandling of Exceptional Conditions - некорректная обработка исключительных ситуаций и ошибок.
Таким образом, OWASP фиксирует очевидный тренд: защита одной только бизнес-логики приложения уже недостаточна. Нужно учитывать то, как код собирается, откуда берутся компоненты, как приложение реагирует на сбои инфраструктуры, сетевые проблемы и нетипичное поведение пользователей или интеграций.
Почему список меняется: не "ради галочки", а вслед за атаками
Обновление OWASP Top 10 - это не косметическое упражнение. Изменения отражают статистику реальных инцидентов и тенденции атак. Распространение атак на цепочки поставок, громкие компрометации популярных библиотек и пакетов, массовые ошибки конфигурации в облаке и Kubernetes - всё это вынудило вынести связанные риски на передний план.
Показательный пример - переосмысление роли логирования и оповещений. Если раньше акцент делался на факте записи событий, то теперь важен полный цикл: сбор, корреляция, анализ и своевременная реакция. Лог, который никто не читает и по которому не поднята тревога, мало чем помогает.
То же самое произошло и с аутентификацией: вместо общего "Authentication and Session Management" акцент всё больше смещается на конкретные уязвимости - слабые механизмы входа, неправильное управление токенами, отсутствие многофакторной аутентификации для чувствительных операций.
Новый фокус: цепочка поставок ПО (A03:2025 Software Supply Chain Failures)
Одна из самых заметных новинок - отдельная категория, связанная с рисками в цепочке поставок программного обеспечения. В неё попадают:
* вредоносные или скомпрометированные зависимости (библиотеки, фреймворки, контейнерные образы);
* атаки на инфраструктуру сборки (подмена артефактов, внедрение кода в pipeline);
* недостаточная проверка целостности загружаемых компонентов;
* отсутствие прозрачности: непонятно, какие зависимости реально используются и из каких источников они попали в проект.
На практике это означает, что даже идеальный с точки зрения внутренней логики код может оказаться уязвим только потому, что использует небезопасную библиотеку или контейнерный образ, в который внедрили бэкдор. Поэтому в 2025 году "безопасная разработка" уже не ограничивается ревью кода и SAST: нужны политики выбора зависимостей, контроль их происхождения, отслеживание версий и автоматическое оповещение о найденных уязвимостях.
Исключительные ситуации и ошибки: новая критическая зона (A10:2025 Mishandling of Exceptional Conditions)
Другая новая категория посвящена тому, как приложение ведёт себя в нештатных ситуациях:
* некорректная обработка исключений;
* раскрытие внутренних деталей (stack trace, SQL-запросы, пути к файлам) пользователю;
* проигнорированные ошибки ввода‑вывода, сетевых подключений, таймаутов;
* отсутствие корректных ограничений при ошибках (например, выключение проверок при сбоях во внешнем сервисе).
Атакующие давно научились использовать эти "краевые сценарии" для обхода защиты. Достаточно вызвать специфическую ошибку или навязать системе нестандартное состояние, чтобы получить больше информации о внутреннем устройстве приложения или добиться выполнения кода в неожиданных условиях.
В 2025 году OWASP подчёркивает: обработка исключений - это не вопрос "красивых сообщений для пользователя", а полноценный элемент модели угроз.
Broken Access Control (A01:2025): почему контроль доступа снова на первом месте
Как и в прошлой редакции, Broken Access Control остаётся главным пунктом списка. Это не случайно: некорректная реализация авторизации и разграничения прав остаётся одной из самых частых и разрушительных проблем.
Категория охватывает любые ситуации, когда пользователь может:
* просматривать данные, к которым у него нет прав;
* изменять или удалять чужие ресурсы;
* выполнять административные или финансовые операции, будучи обычным пользователем;
* обращаться к внутренним сервисам и файлам, не предназначенным для внешнего доступа.
В версии 2025 сюда дополнительно включены риски, ранее выделенные отдельно как Server-Side Request Forgery (SSRF). Раньше SSRF фигурировала в списке под собственной позицией, теперь её рассматривают как частный случай нарушенного контроля доступа к ресурсам. Логика проста: корень проблемы один - приложение позволяет обращаться к тому, что должно быть недоступно.
Пример: path traversal и утечка файлов
Рассмотрим типичный фрагмент кода, где путь к файлу берётся из пользовательского ввода и почти не проверяется:
```csharp
public string ReadFile(string pathInput)
{
if (pathInput == null)
throw new ArgumentNullException(nameof(pathInput));
return File.ReadAllText(pathInput);
}
```
Статический анализатор (например, PVS-Studio) способен выдать предупреждение уровня:
> Возможная уязвимость типа path traversal. Потенциально небезопасные данные из переменной `pathInput` используются как путь к файлу.
Проблема в том, что параметр `pathInput` принимается "как есть". Пользователь может подставить что-то вроде:
```text
../../../etc/passwd
```
и получить доступ к произвольным файлам на сервере. Это классическая уязвимость path traversal: разработчик предполагал, что путь будет указывать на определённый каталог, но никак это не зафиксировал.
Безопасная реализация должна:
* ограничивать работу только внутри заранее определённого каталога;
* нормализовать путь (убирать `../` и другие попытки выхода за пределы);
* дополнительно проверять, что результирующий путь действительно находится внутри разрешённой директории.
Логические ошибки в авторизации: когда код "по умолчанию" разрешает всё
Не все проблемы с контролем доступа сводятся к путям и файловой системе. Часто уязвимости скрываются на уровне бизнес-логики или фреймворков безопасности.
Например, в приложении на Spring разработчик реализует собственный `AccessDecisionVoter`, но допускает критическую логическую ошибку:
```java
public int vote(Authentication authentication, Object object, Collection attributes) {
// ... некоторая логика проверки,
// которая на деле всегда возвращает ACCESS_GRANTED
return AccessDecisionVoter.ACCESS_GRANTED;
}
```
В результате:
* обычный пользователь может выполнять административные операции;
* запреты формально описаны, но фактически игнорируются;
* принцип минимальных привилегий полностью нарушается.
Подобная ошибка может быть выявлена статическими анализаторами по шаблону "слишком разрешающая авторизация". Инструмент вроде PVS-Studio способен среагировать правилом, указывающим на использование небезопасно "широких" проверок доступа, которые приводят к нарушениям безопасности.
Роль SAST: где статический анализ действительно помогает
Статический анализ исходного кода (SAST) давно стал обязательным элементом безопасной разработки. Он особенно полезен как раз в контексте OWASP Top 10:
* Broken Access Control - выявление подозрительных мест, где пользовательские данные используются для построения путей, URL, параметров запросов без валидации;
* Injection и Cryptographic Failures - обнаружение небезопасных SQL-конкатенаций, неправильного использования криптографических примитивов, слабых алгоритмов;
* Security Misconfiguration - детекция жёстко зашитых паролей, небезопасных флагов конфигурации, отключенного шифрования;
* Software or Data Integrity Failures - поиск мест, где загружаемые артефакты, скрипты или плагины не проверяются на целостность и подлинность.
У PVS-Studio и других промышленных SAST-инструментов есть отдельные группы диагностических правил, ориентированных именно на OWASP Top 10. Это позволяет проецировать требования из стандарта непосредственно на проверяемый код, а не работать только с абстрактными рекомендациями.
Важно понимать, что статический анализ не заменяет все остальные меры: он не знает про реальную конфигурацию продакшена или бизнес-контекст. Но он даёт возможность массово и автоматизированно находить типовые шаблоны уязвимостей ещё до того, как код попадает в репозиторий основной ветки.
От кода к процессам: безопасность как часть SDLC
OWASP Top 10 уже не сводится к набору "ошибок программиста". Список всё сильнее затрагивает организационные аспекты:
* как устроен процесс ревью и кто отвечает за риск‑анализ;
* есть ли у команды политика выбора третьесторонних библиотек;
* фиксируются ли версии зависимостей и есть ли централизованный их учёт;
* проверяются ли контейнерные образы и манифесты инфраструктуры как код;
* насколько регулярно обновляются сторонние компоненты и сам фреймворк.
В 2025 году безопасная разработка - это совокупность практик: SAST, DAST, анализ зависимостей, контроль цепочки поставок, настройка мониторинга и alerting, обучение разработчиков типовым паттернам уязвимостей.
Как разработчикам и ИБ-специалистам адаптироваться под OWASP Top 10:2025
Чтобы изменения в OWASP Top 10 не остались теорией, их нужно приземлить в ежедневную работу команды. Практические шаги могут выглядеть так:
1. Актуализировать модель угроз продукта. Перепроверить, как в ней отражены риски цепочки поставок, обработки ошибок, конфигурации CI/CD.
2. Обновить чек-листы ревью кода. Включить проверки на path traversal, SSRF, чрезмерно широкие права, корректность обработки исключений.
3. Интегрировать SAST в pipeline. Запускать статический анализ на каждом merge request, а не только перед релизом.
4. Ввести обязательную валидацию пользовательского ввода. Централизовать её в отдельных компонентах/библиотеках, чтобы не дублировать проверку вручную.
5. Наладить управление зависимостями. Вести перечень используемых библиотек и образов, следить за их обновлениями, использовать только доверенные источники.
6. Проверить систему логирования и оповещений. Убедиться, что критичные события не только пишутся в лог, но и приводят к алертам и разбору инцидентов.
Глубже в Broken Access Control: типовые ошибки и подходы к защите
Контроль доступа остаётся самым сложным для автоматизации аспектом, поскольку он тесно связан с бизнес-логикой. Типичные проблемы:
* Отсутствие серверной проверки. Разработчик полагается на скрытые элементы интерфейса, но не дублирует проверки на бэкенде.
* IDOR (Insecure Direct Object Reference). Пользователь может получить доступ к ресурсу, просто подставив другой идентификатор в URL или тело запроса.
* Неоднородные политики. В разных частях кода применяются разные правила, что приводит к "дырам" при сложных сценариях.
* Смешение аутентификации и авторизации. Система "узнаёт" пользователя, но не проверяет, что он имеет право на конкретное действие.
Эффективной стратегией защиты становится централизация авторизации: единый слой или сервис, через который проходят все критичные операции. Это снижает риск появления разрозненных "ручных" проверок и упрощает аудит.
Объединение SSRF с Broken Access Control: логика OWASP
Решение включить SSRF внутрь Broken Access Control подчёркивает концептуальный сдвиг. В фокусе больше не сам по себе тип запроса (HTTP, gRPC и т.п.), а суть нарушения: возможность обратиться к тому, что должно быть недоступно.
При SSRF злоумышленник заставляет приложение совершить запрос во внутреннюю сеть, к метаданным облака или к сервисам, которые изначально не предполагались для внешнего доступа. Если рассматривать это как ошибку контроля доступа, становится понятно, что защищать нужно не только пользовательские ресурсы, но и инфраструктурные.
Практически это означает:
* жёстко ограничивать, куда приложение может ходить по сети;
* не позволять пользователю напрямую задавать URL для серверных запросов;
* использовать списки разрешённых адресов и сервисов;
* фильтровать и нормализовать любые исходящие запросы, параметры которых зависят от пользовательского ввода.
Заключение: от устранения багов к управлению рисками
OWASP Top 10:2025 демонстрирует, что безопасность веб‑приложений уже давно вышла за рамки простого "закрытия дыр в коде". Теперь речь идёт о комплексном управлении рисками:
* от качества исходного кода и корректной реализации авторизации;
* до контроля цепочки поставок, настройки инфраструктуры, обработки исключений;
* от точечных исправлений - к системным практикам в рамках всего жизненного цикла разработки.
Статический анализ, такой как SAST-инструменты уровня PVS-Studio, помогает своевременно вылавливать типовые уязвимости и логические ошибки на раннем этапе. Но максимальный эффект достигается только тогда, когда он становится частью целостного процесса: с продуманной моделью угроз, управлением зависимостями, регулярным обучением команды и опорой на актуальные рекомендации OWASP.
В 2025 году выиграют те команды, которые воспринимают OWASP Top 10 не как формальную "галочку", а как практический чек-лист для развития своих процессов и архитектуры.
