OWASP Top 10 2025: 10 критических уязвимостей веб-приложений — полный разбор

В статье — разбор каждой из десяти категорий owasp top 10 2025: какие атаки они описывают, как обнаружить уязвимость и чем её закрыть. Дополнительно: сравнительная таблица изменений с версией 2021 года, матрица покрытия средствами защиты и приоритизированный чеклист для команды разработки.

Что такое OWASP Top 10 и кто за ним стоит

OWASP расшифровывается как Open Worldwide Application Security Project — открытый международный проект по безопасности приложений. Это некоммерческое сообщество, основанное в 2001 году: все публикуемые материалы доступны бесплатно командам разработки, аудиторам и регуляторам по всему миру.

OWASP Top 10 — ключевой документ сообщества: список десяти наиболее критичных рисков безопасности веб-приложений. Де-юре стандартом не является, но де-факто на него ссылаются требования PCI DSS, ISO 27001-аудиторы и технические задания на разработку защищённого ПО. Выходит раз в несколько лет: версии 2013, 2017, 2021 и теперь 2025.

Как формируется список:

1. Частота — OWASP Foundation собирает данные о реальных уязвимостях от организаций-партнёров по всему миру: тысячи приложений, сотни тысяч задокументированных проблем.
2. Ущерб — каждая категория оценивается по сложности эксплуатации и потенциальному ущербу для бизнеса.
3. CWE — уязвимостям присваиваются идентификаторы из реестра типовых слабостей программного обеспечения CWE (Common Weakness Enumeration), который ведёт организация MITRE.
4. Позиция — по совокупному баллу формируется финальный порядок десяти категорий.

Реестр CWE насчитывает более тысячи классифицированных записей. Он служит единым техническим языком: когда инструмент статического анализа кода (SAST, Static Application Security Testing) сообщает «CWE-89», это SQL-инъекция — без расхождений в терминологии между командами и инструментами.

№1. Программа «Кибербезопасность» АМСЗ — освоить защиту от угроз OWASP Top 10

Специалист по кибербезопасности работает с угрозами из OWASP Top 10 ежедневно: настраивает межсетевые экраны для веб-приложений, анализирует журналы событий, реагирует на инциденты, контролирует конфигурации. Если тема безопасности веб-приложений — не только справочный материал, а направление развития, федеральный проект «Активные меры содействия занятости» (АМСЗ) в рамках нацпроекта «Кадры» позволяет освоить профессию без вложений.

Программа: «Кибербезопасность: администрирование и мониторинг средств защиты информации» — 144 часа, уровень с нуля.

Таблица. Ключевые параметры программы «Кибербезопасность» в рамках АМСЗ.

Статистика проекта: более 200 000 человек прошли обучение по программам АМСЗ, 85% из них трудоустроились. Центр карьеры предоставляет доступ к 7 500+ актуальным вакансиям, HR-консультациям и разбору карьерной стратегии.

Смотрите программу и другие направления в каталоге бесплатных программ.

OWASP Top 10:2025 против 2021 — что изменилось

Две принципиальных новинки версии 2025 года: совершенно новая категория A10 о поведении системы при сбоях и A03, расширенная от «устаревших компонентов» до атак на весь жизненный цикл разработки. SSRF поглощён A01; A02 Security Misconfiguration поднялась с пятого на второе место — признак того, что ошибки конфигурации стали массовым вектором атак.

Общий тренд: список движется от «ошибок в коде» к «системным рискам всего жизненного цикла ПО» — цепочки поставок, CI/CD-пайплайны (конвейеры непрерывной интеграции и доставки), поведение системы при отказах.

A01:2025 — Broken Access Control (Сломанный контроль доступа)

Позиция: #1 — не изменилась с 2021; в версии 2025 года категория поглотила SSRF (Server-Side Request Forgery, подделку запросов на стороне сервера).

Broken Access Control объединяет уязвимости, при которых пользователь получает доступ к ресурсам или действиям, которые ему не разрешены. Ошибки доступа завязаны на бизнес-логику и плохо обнаруживаются автоматическими сканерами — поэтому категория удерживает первое место.

Основные паттерны атак:

• IDOR (Insecure Direct Object Reference, небезопасная прямая ссылка на объект) — злоумышленник меняет числовой идентификатор в URL (/order/123 → /order/124) и получает доступ к чужим данным.
• Path Traversal (CWE-22) — подъём по дереву директорий через ../ для чтения произвольных файлов сервера.
• Privilege Escalation (повышение привилегий) — вызов эндпоинта, доступного только администратору, от имени обычного пользователя.

Пример уязвимого кода и исправленного варианта (Flask):

# Уязвимо — нет проверки владельца объекта

order = Order.query.get(order_id)

return order.to_json()

# Безопасно — проверка прав на сервере, не только на фронтенде

order = Order.query.get(order_id)

if order.user_id != current_user.id:

abort(403)

return order.to_json()

Ключевые CWE: CWE-22, CWE-200, CWE-359, CWE-566, CWE-732.

Защита: проверка прав в серверном коде при каждом запросе; ролевая модель разграничения доступа (RBAC, Role-Based Access Control); межсетевой экран для веб-приложений для rate limiting как дополнительный рубеж.

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

Позиция: #2 (↑ с пятого в 2021) — резкий подъём объясняется массовым переходом на облака и контейнеры, где ошибки конфигурации воспроизводятся в промышленных масштабах.

Типичные примеры: включённый режим отладки (debug mode) в продакшен-среде, дефолтные пароли на СУБД и панелях управления, избыточные HTTP-методы, публичные облачные бакеты, широкие права сервисных аккаунтов.

Отдельная угроза — XXE-атака (XML External Entity, внешняя XML-сущность): небезопасно сконфигурированный XML-парсер позволяет злоумышленнику читать локальные файлы сервера через подставную внешнюю сущность в XML-документе (CWE-611).

Ключевые CWE: CWE-611 (XXE), CWE-315, CWE-526, CWE-942.

Защита: hardening (ужесточение конфигурации) по стандарту CIS Benchmarks; проверки конфигурации инфраструктуры как кода (IaC) в CI/CD-пайплайне; строгое разделение настроек dev/staging/prod; отключение обработки внешних XML-сущностей по умолчанию. Принцип минимальной поверхности атаки: всё, что не нужно — отключено.

A03:2025 — Software Supply Chain Failures (Уязвимости цепочки поставок)

Позиция: #3; расширена из A06:2021 «Vulnerable and Outdated Components» (уязвимые и устаревшие компоненты) до рисков всего жизненного цикла разработки и доставки программного обеспечения.

Атака на цепочку поставок нередко эффективнее прямого взлома: достаточно скомпрометировать одну популярную зависимость — и получить доступ ко всем её потребителям. Поверхности атак: пакеты npm/pip/Maven, Docker-образы, внешние шаги GitHub Actions, сторонние реестры артефактов, незащищённые CI/CD-пайплайны.

Ключевые CWE: CWE-477, CWE-1035, CWE-1104, CWE-1329, CWE-1395.

Защита: анализ состава программного обеспечения (SCA, Software Composition Analysis) — инструменты Snyk или OWASP Dependency-Check; ведение реестра зависимостей (SBOM, Software Bill of Materials) для всего проекта; цифровые подписи артефактов сборки; ограничение прав CI/CD-пайплайна по принципу минимальных привилегий.

A04:2025 — Cryptographic Failures (Криптографические уязвимости)

Позиция: #4 (↓ со второго в 2021) — некоторое улучшение практик, однако категория остаётся в топе из-за устойчивого применения слабых алгоритмов в унаследованных (legacy) системах.

Типичные ошибки: хеширование паролей через MD5 или SHA-1 без соли (CWE-916), хранение паролей в открытом виде, секреты прямо в коде (hardcoded secrets), слабый генератор псевдослучайных чисел (PRNG, CWE-338), передача данных по HTTP вместо HTTPS.

Пример перехода с небезопасного к безопасному хешированию:

# Уязвимо — MD5 без соли

import hashlib

hashed = hashlib.md5(password.encode()).hexdigest()

# Безопасно — bcrypt с rounds=12

import bcrypt

hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

Ключевые CWE: CWE-296, CWE-335, CWE-338, CWE-757, CWE-916.

Защита: bcrypt (rounds=12) или Argon2 для хеширования паролей — bcrypt заменяет MD5 как стандарт хранения; Secret Manager вместо секретов в репозитории; принудительный TLS 1.3 на всех соединениях; регулярный аудит используемых алгоритмов.

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

Позиция: #5 (↓ с третьего в 2021) — улучшение автоматизированного тестирования снизило позицию, но не актуальность категории.

Инъекции возникают, когда непроверенные пользовательские данные попадают в интерпретатор как часть команды или запроса. Типы: SQL-инъекция (CWE-89), внедрение команд ОС (OS Command Injection, CWE-78), LDAP-инъекция (CWE-90), межсайтовый скриптинг (XSS, CWE-79), внедрение в шаблоны (Template Injection).

Пример уязвимого и защищённого SQL-запроса:

# Уязвимо — конкатенация строк

query = «SELECT * FROM users WHERE email = ‘» + email + «‘»

# Безопасно — параметризованный запрос (Python)

cursor.execute(«SELECT * FROM users WHERE email = %s», (email,))

// Безопасно — PHP PDO

$stmt = $pdo->prepare(«SELECT * FROM users WHERE email = ?»);

$stmt->execute([$email]);

Параметризованные запросы — единственный надёжный способ защиты от SQL-инъекций. Конкатенация строк в SQL-запросах — уязвимость всегда, независимо от наличия иных средств защиты. Дополнительно: ORM с типобезопасными запросами, валидация пользовательского ввода по схеме. Межсетевой экран для веб-приложений (WAF) закрывает типовые сигнатуры инъекций, но выступает только вторым эшелоном — не заменяет параметризацию.

Ключевые CWE: CWE-77, CWE-78, CWE-79, CWE-89, CWE-90, CWE-643.

A06:2025 — Insecure Design (Небезопасная архитектура)

Позиция: #6 (↓ с четвёртого) — снижение позиции не означает снижения актуальности: другие категории выросли сильнее.

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

Классический пример Insecure Design: перевод денег между счетами без проверки баланса, прав доступа и идемпотентности операции. Это архитектурное решение — точнее, его отсутствие.

Инструменты статического анализа не выявляют небезопасную архитектуру напрямую: они анализируют синтаксис и паттерны, а не намерения проектировщика. Необходимы: моделирование угроз (Threat Modeling) до написания первой строки кода, подход Security-by-Design (безопасность по умолчанию) и архитектурный код-ревью на этапе проектирования.

A07:2025 — Authentication Failures (Уязвимости аутентификации)

Позиция: #7 (не изменилась); в 2025 году категория переименована с «Identification and Authentication Failures» — новое название точнее соответствует связанным идентификаторам CWE.

Симптомы: политика паролей отсутствует или тривиальна, многофакторная аутентификация (MFA) не применяется, токены восстановления предсказуемы, сессии живут дольше необходимого. Уязвимость к атаке с перебором учётных данных (Credential Stuffing) — когда злоумышленник использует утёкшие с других сервисов пары логин/пароль — напрямую следует из отсутствия rate limiting и MFA.

Ключевые CWE: CWE-288, CWE-303, CWE-307, CWE-640.

Защита: MFA для всех привилегированных аккаунтов; bcrypt для хеширования паролей; rate limiting и блокировка после N неудачных попыток входа; короткоживущие сессии со своевременной инвалидацией.

A08:2025 — Software or Data Integrity Failures (Нарушения целостности)

Позиция: #8; в 2025 году уточнено название — союз «and» заменён на «or» для большей точности: нарушение целостности может касаться кода или данных независимо друг от друга.

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

Ключевые CWE: CWE-565, CWE-829, CWE-830, CWE-915.

Защита: whitelist разрешённых классов при десериализации; цифровые подписи для всех артефактов автообновления; безопасные библиотеки сериализации с жёсткими схемами; валидация источника вебхуков через HMAC-подписи запросов.

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

Позиция: #9; переименована: слово «Monitoring» заменено на «Alerting» — акцент смещён с пассивной записи событий на активное оповещение при аномалиях.

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

Что логировать: попытки входа (успешные и неудачные), изменения прав доступа, обращения к чувствительным данным, административные операции.

Что не логировать: пароли, персональные данные и номера платёжных карт в открытом виде — это само по себе создаёт уязвимость; также опасен Log Injection через незащищённые пользовательские данные в сообщениях журнала.

Защита: централизованные журналы на изолированном сервере; SIEM (Security Information and Event Management, система управления событиями информационной безопасности) для корреляции событий; алерты на серии неудачных попыток входа, всплески ошибок 5xx и нетипичную активность в нерабочее время.

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

Позиция: #10 — совершенно новая категория версии 2025 года. Впервые в истории OWASP Top 10 фокусируется на поведении системы при сбоях, а не на уязвимостях в штатном потоке исполнения.

Последствия некорректной обработки исключений:

• Утечка трассировки стека — подробный stack trace в HTTP-ответе раскрывает внутреннюю архитектуру, версии библиотек и пути файлов.
• Отказ в обслуживании (DoS) — необработанное исключение завершает поток или процесс.
• Обход аутентификации — пустой catch {} может вернуть пользователю права по умолчанию вместо ошибки.

Антипаттерны кода:

// Опасно — пустой catch: пользователь получает доступ без аутентификации

try {

authenticate(user);

} catch (Exception e) {

// ничего не делаем

}

// Опасно — создание Exception без throw: контекст ошибки теряется

Exception ex = new Exception(«auth failed»);

Ключевые CWE: CWE-209, CWE-280, CWE-478, CWE-703, CWE-754.

Защита: Fail-Safe Defaults — по умолчанию запрет, а не разрешение при сбое; Circuit Breaker (автоматический прерыватель цепочки отказов) для внешних зависимостей; маскирование внутренних деталей во внешних HTTP-ответах; логирование всех исключений с полным стеком для внутреннего анализа.

WAF и SAST: покрытие угроз OWASP Top 10:2025 — сравнительная таблица

Ни один инструмент не закрывает все десять категорий owasp top 10 в одиночку. Матрица покрытия помогает понять, где остаются пробелы.

Межсетевой экран для веб-приложений (WAF, Web Application Firewall) работает на уровне HTTP-трафика и применяет правила набора OWASP CRS 4.0. Хорошо перехватывает инъекции по сигнатурам (A05) и XSS; частично помогает с A01 (rate limiting), A02 (защитные HTTP-заголовки) и A07 (защита от ботов). Архитектурные проблемы A06, атаки на цепочку поставок A03 и ошибки обработки исключений A10 WAF не решает.

Статический анализатор кода (SAST) работает во время разработки, до деплоя. Выявляет небезопасные паттерны в коде: криптографические ошибки (A04), инъекции (A05), проблемы логирования (A09) и опасные конструкции обработки исключений (A10). Не способен обнаружить архитектурные дефекты A06 — они лежат выше уровня кода — и не видит транзитивные зависимости из зоны A03.

Три взаимодополняющих слоя — WAF + SAST + SCA — формируют подход DevSecOps (встроенная безопасность в цикл разработки). Они не конкурируют: каждый закрывает то, что другой не видит. Только вместе они дают системное покрытие большинства угроз из списка.

Чеклист защиты по OWASP Top 10:2025 — с чего начать

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

Приоритет 1 — быстрые меры (базовый уровень):

• Параметризованные запросы везде, где есть обращения к базе данных (A05).
• bcrypt или Argon2 вместо MD5/SHA-1 для хранения паролей (A04).
• Проверка прав доступа на сервере при каждом запросе; RBAC (A01).

Приоритет 2 — процессы (продвинутый уровень):

• Hardening конфигурации по CIS Benchmarks, проверки в CI/CD-пайплайне (A02).
• SCA-сканирование зависимостей и ведение SBOM (A03).
• MFA для привилегированных аккаунтов; rate limiting на форму входа (A07).

Приоритет 3 — зрелость:

• Threat Modeling на этапе проектирования каждой новой функции (A06).
• SIEM с алертами на аномалии; централизованные журналы (A09).
• Fail-Safe Defaults и Circuit Breaker для обработки исключений (A10).
• Whitelist классов при десериализации; цифровые подписи артефактов (A08).

Финальная цель — DevSecOps-контур: SAST в CI/CD-пайплайне, WAF в промышленном контуре, Secret Manager вместо переменных с секретами в репозитории. При таком подходе большинство угроз OWASP Top 10 перехватывается до попадания в продакшен.

Часто задаваемые вопросы

Что включает в себя OWASP Top 10:2025?

Десять категорий рисков: A01 Broken Access Control, A02 Security Misconfiguration, A03 Software Supply Chain Failures, A04 Cryptographic Failures, A05 Injection, A06 Insecure Design, A07 Authentication Failures, A08 Software or Data Integrity Failures, A09 Security Logging & Alerting Failures, A10 Mishandling of Exceptional Conditions. По сравнению с 2021 годом появились две новые: A03 (расширена из Vulnerable Components) и A10 (абсолютно новая категория).

Чем OWASP Top 10:2025 отличается от версии 2021 года?

Две принципиальных новинки: A03 Software Supply Chain Failures — расширена с «устаревших компонентов» до атак на весь жизненный цикл ПО — и A10 Mishandling of Exceptional Conditions, первая категория о поведении системы при сбоях. SSRF поглощён A01. A02 Security Misconfiguration поднялась с пятого на второе место — признак резкого роста угрозы через ошибки конфигурации.

Что такое Broken Access Control и почему он на первом месте?

A01 Broken Access Control объединяет уязвимости несанкционированного доступа: IDOR (смена ID в URL → чужие данные), Path Traversal, Privilege Escalation. На первом месте потому, что ошибки доступа завязаны на бизнес-логику и плохо обнаруживаются автоматическими сканерами. Решение: проверять права на сервере при каждом запросе, а не только на фронтенде, и внедрить RBAC.

Как защититься от SQL-инъекций?

Единственный надёжный способ — параметризованные запросы: cursor.execute(«SELECT … WHERE email = %s», (email,)). Конкатенация строк в SQL-запросах — всегда уязвимость, независимо от наличия WAF. Дополнительно: ORM с типобезопасными запросами, минимальные права учётной записи базы данных, валидация входных данных по схеме. WAF закрывает типовые сигнатуры, но не заменяет параметризацию.

Что такое Software Supply Chain Failures (A03:2025)?

Риски через сторонние компоненты и инфраструктуру сборки: зависимости npm/pip/Maven, Docker-образы, внешние шаги GitHub Actions, незащищённые CI/CD-пайплайны. Атака на цепочку поставок нередко эффективнее прямого взлома: достаточно скомпрометировать одну популярную библиотеку. Защита: SCA для аудита зависимостей, SBOM для их учёта, цифровые подписи артефактов сборки.

Что такое A10:2025 — Mishandling of Exceptional Conditions?

Первая в истории OWASP категория о поведении системы при сбоях. Пустой catch {} может дать пользователю авторизацию по умолчанию; трассировка стека в HTTP-ответе раскрывает внутренние данные; необработанное исключение завершает поток — доступность сервиса нарушена. Антипаттерны: создание объекта Exception без throw, перетирание стека при повторном бросе. Защита: Circuit Breaker, Fail-Safe Defaults, маскирование ошибок во внешних ответах.

Заменяет ли WAF безопасный код?

Нет. WAF — второй эшелон: хорошо перехватывает A05 Injection и XSS по сигнатурам, частично помогает с A01 (rate limiting) и A07 (защита от ботов). Но не решает архитектурные проблемы A06, не помогает с A03 (цепочка поставок) и A10 (обработка исключений). Правило простое: WAF дополняет безопасный код, но никогда его не заменяет.

Чем OWASP Top 10 для веба отличается от OWASP для языковых моделей и мобильных приложений?

OWASP ведёт три самостоятельных проекта: OWASP Top 10 (веб-приложения — тема этой статьи), OWASP LLM Top 10 (угрозы языковых моделей: Prompt Injection, Training Data Poisoning) и OWASP Mobile Top 10 (мобильные приложения). Списки не взаимозаменяемы: угрозы и методика отбора категорий в каждом проекте существенно различаются.

Как связаны OWASP Top 10 и OWASP API Security Top 10?

OWASP API Security Top 10 — отдельный проект для REST/GraphQL/gRPC API. Многие категории пересекаются (Injection, Authentication Failures актуальны для обоих), но API-специфичные угрозы — авторизация на уровне объектов (Object Level Authorization, API-аналог IDOR), избыточное раскрытие данных — вынесены в отдельный список. При разработке API нужно учитывать оба документа.

Что такое CWE и как он связан с OWASP Top 10?

CWE (Common Weakness Enumeration) — стандартизированный перечень типов слабостей программного обеспечения от MITRE, содержащий более тысячи записей. Каждая категория OWASP Top 10 содержит список связанных CWE: A05 Injection → CWE-89 (SQL-инъекция), CWE-79 (XSS). Инструменты статического анализа используют CWE-идентификаторы в предупреждениях — это позволяет командам говорить об уязвимостях на едином языке без терминологических расхождений.