OWASP Top 10 2025: обновлённый список с пояснениями (A01–A10)

Что такое OWASP Top 10 2025 и что изменилось

OWASP Top 10 — создаваемый сообществом информационный документ, который ранжирует самые критичные риски безопасности веб-приложений. Его поддерживает Open Worldwide Application Security Project, и он обновляется примерно раз в три-четыре года на основе присылаемых данных тестирования приложений и опроса практиков, поэтому каждое издание отражает реальное поведение злоумышленников, а не абстрактную теорию.

Издание 2025 года сохраняет нарушенный контроль доступа на первом месте и по-прежнему рассматривает целые категории слабых мест, а не отдельные ошибки. Главные изменения — усиленный акцент на небезопасной конфигурации в облаке и CI/CD, повышение значимости рисков цепочки поставок ПО за пределы уязвимых компонентов и явное внимание к неверно обработанным ошибкам и исключениям, которые незаметно раскрывают данные или отказывают в открытом состоянии.

Поскольку на список ссылаются множество стандартов и регуляторов, Top 10 стал фактическим базовым уровнем. Аудиторские ожидания CERT-In в Индии, требования безопасности RBI и SEBI, европейские NIS2 и DORA, а также анкеты безопасности крупных компаний США исходят из того, что ваши приложения проверены по этим категориям. Считайте список минимальным объёмом, а не финишной чертой.

A01: Нарушенный контроль доступа

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

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

A02: Небезопасная конфигурация

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

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

A03: Сбои цепочки поставок программного обеспечения

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

Мера защиты: вести перечень состава ПО (SBOM), фиксировать и проверять зависимости и защищать сам конвейер сборки, чтобы к выпуску допускались только проверенные артефакты с подтверждённой целостностью.

A04: Криптографические сбои

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

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

A05: Инъекции

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

Мера защиты: использовать параметризованные запросы и безопасные API, передающие ввод как данные, проверять ввод по строгим спискам разрешённого и кодировать вывод с учётом контекста, чтобы пользовательский контент никогда не мог быть исполнен.

A06: Небезопасное проектирование

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

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

A07: Сбои аутентификации

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

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

A08: Сбои целостности программного обеспечения и данных

Сбои целостности возникают, когда коду или критичным данным доверяют без проверки на подмену: неподписанные автообновления, небезопасная десериализация недоверенных объектов или шаги CI/CD, загружающие артефакты без проверки целостности. Тот, кто может подменить доверенный источник, получает контроль над приложением.

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

A09: Сбои журналирования и оповещения

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

Мера защиты: журналировать значимые для безопасности события с достаточным контекстом для расследования, централизовать и защищать эти журналы и связывать их с оповещением в реальном времени и процессом реагирования на инциденты — обязанность, усиленная требованием CERT-In хранить журналы в Индии 180 дней.

A10: Неверная обработка исключительных ситуаций

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

Мера защиты: отказывать безопасно и «в закрытое состояние», возвращать пользователям обобщённые сообщения об ошибках, журналируя полные подробности на сервере, и намеренно тестировать исключительный и неожиданный ввод, а не только штатный сценарий.

Чем помогает IntelligenceX

OWASP Top 10 2025 — карта того, где искать, но охват имеет значение, только если ваши приложения действительно проверены по нему. IntelligenceX оценивает каждую категорию с помощью преимущественно ручных услуг в соответствии с OWASP и даёт рекомендации, готовые для разработчиков, — подход, подходящий заказчикам в Великобритании, США, ЕС и Индии.

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

Для организаций под регулированием Индии такое тестирование напрямую соотносится с обязанностями по мерам защиты закона DPDP и ожиданиями CERT-In, RBI, SEBI и IRDAI. Чтобы обозначить границы: IntelligenceX консультирует, оценивает и готовит и в настоящее время не имеет аккредитации CERT-In; мы не выдаём сертификаты и не подписываем регуляторные аудиты. Свяжитесь с нашей командой, чтобы определить объём оценки ваших приложений.