OWASP Top 10 — 2026: главные уязвимости веб-приложений и методы защиты

📋 Кратко

OWASP Top 10 — 2026 пересмотрел приоритеты: на первое место вышли ошибки управления доступом (Broken Access Control) и криптографические уязвимости (Cryptographic Failures). В топ-10 вошли новые угрозы — SSRF, уязвимости в цепочках поставок ПО и проблемы безопасности API. Разбираем каждую категорию с примерами атак, чек-листами защиты и рекомендациями для CI/CD-пайплайнов.

Иллюстрация к статье

Введение: почему OWASP Top 10 остаётся главным ориентиром

OWASP (Open Web Application Security Project) — некоммерческая организация, чей рейтинг Top 10 стал общепризнанным стандартом для оценки защищённости веб-приложений. Каждые 3–4 года OWASP обновляет список, отражая изменения в ландшафте угроз: новые способы атак, развитие уязвимостей и изменения в архитектуре приложений.

По данным отчёта Positive Technologies за 2025 год, 67% веб-приложений содержат хотя бы одну критическую уязвимость из списка OWASP Top 10. Средний ущерб от эксплуатации таких уязвимостей в 2025 году достиг $4,2 млн на одну атаку — рост на 23% по сравнению с 2023 годом. Наиболее уязвимы следующие сферы: здравоохранение (средний ущерб $8,6 млн), финансы ($6,1 млн) и государственные услуги ($5,4 млн).

⚠ Ключевая статистика: В 2025 году 72% всех атак на веб-приложения использовали уязвимости из первой пятёрки OWASP Top 10 — Broken Access Control, Cryptographic Failures, Injection, Insecure Design и Security Misconfiguration.

Источник: OWASP Foundation, Positive Technologies Web App Security Report 2025.

1. Broken Access Control — выход на первое место

Broken Access Control (нарушение прав доступа) — самая распространённая категория уязвимостей. Она охватывает: IDOR (Insecure Direct Object Reference — манипуляция ID объектов), path traversal (выход за пределы директории), privilege escalation (повышение привилегий) и missing function-level access control (отсутствие проверки доступа к функциям).

По данным OWASP, эта категория присутствует в 94% протестированных приложений со средним показателем 3,2 уязвимости на приложение. Самая частая ошибка — доверие к клиентским ID (например, передача user_id=123 в параметрах запроса) и отсутствие проверки на серверной стороне.

Практический пример

Разработчики CRM-системы для малого бизнеса оставили адрес запроса /api/users/{id}/profile без проверки — любой авторизованный пользователь мог просмотреть профиль любого другого пользователя, изменив ID в URL. Злоумышленник, зарегистрировавшись как обычный пользователь, за 15 минут собрал базу данных всех 12 000 сотрудников, включая паспортные данные и зарплатные ведомости.

Методы защиты

  • Принцип наименьших привилегий (PoLP) — каждый пользователь/сервис получает ровно тот доступ, который нужен для работы
  • Обязательная проверка на серверной стороне — никогда не полагаться на параметры из URL или тела запроса для идентификации прав
  • Референсные мониторы (reference monitor) — централизованная проверка каждого запроса к защищённому ресурсу
  • WAF-правила для обнаружения манипуляций с ID (шаблоны /api/users/{integer}/)
Иллюстрация к статье

2. Cryptographic Failures — когда защита оборачивается угрозой

Cryptographic Failures (криптографические сбои) — это не только атаки на слабое шифрование, но и его отсутствие там, где оно необходимо. Ошибки протоколов TLS/SSL, использование устаревших алгоритмов (MD5, SHA-1), хранение паролей в открытом виде — все эти проблемы OWASP объединил в одну категорию.

Исследование Positive Technologies показало: 41% веб-приложений передают конфиденциальные данные (пароли, токены, номера карт) по незащищённым каналам. Ещё 27% используют самоподписанные или устаревшие сертификаты TLS. Особенно остро проблема стоит в API-шлюзах — 53% публичных API не используют HTTPS для всех точек входа.

⚠ Ключевой вывод: По данным OWASP, 78% критических уязвимостей уровня HIGH/CRITICAL за 2025 год пришлись на одну из двух категорий: Broken Access Control или Cryptographic Failures. В 2022 году этот показатель составлял 52% — рост на 26 процентных пунктов.

Источник: OWASP Top 10 Community Survey 2025, 800+ респондентов.

Чек-лист защиты

  • HTTPS везде — все точки входа API, включая внутренние, должны использовать TLS 1.3
  • Отказ от устаревших алгоритмов — MD5, SHA-1, RC4, DES — под полным запретом
  • Хранилище секретов — пароли, ключи API, токены JWT — ни в коде, ни в репозитории
  • Регулярный аудит сертификатов — certificate transparency, мониторинг срока действия

3. Injection — SQL, NoSQL, OS Command, LDAP

Injection (внедрение кода) — классика веб-безопасности, которая никуда не ушла. Хотя SQL-инъекции больше не занимают первое место, они остаются одной из самых опасных категорий: по данным Akamai, в 2025 году ежедневно фиксируется более 340 000 попыток SQL-инъекций.

Главная причина — ORM-фреймворки (Object-Relational Mapping) не всегда защищают от инъекций: разработчики часто используют raw() запросы или передают нефильтрованные параметры в ORM-запросы. Отдельный рост — NoSQL-инъекции (MongoDB, Couchbase), где уязвимости в JSON-запросах позволяют обходить аутентификацию и получать доступ к данным.

Чек-лист защиты

  • Параметризованные запросы — всегда используйте prepared statements вместо конкатенации строк
  • Валидация входных данных — проверяйте типы, длины и форматы всех полей на серверной стороне
  • Ограничение прав БД — у приложения должны быть права только на чтение/запись конкретных таблиц, не всей базы
  • Экранирование спецсимволов — для NoSQL-запросов фильтруйте операторы ($gt, $ne, $where)

4. Insecure Design — архитектурные уязвимости

Insecure Design (небезопасная архитектура) — новая категория, выделенная OWASP в 2021 году и закреплённая в 2026. Это не ошибки кода, а ошибки проектирования: отсутствие threat modelling, неучтённые сценарии атак, недостаточная сегментация.

Пример: архитектура «всё в одной базе данных» — любой пользователь (даже гость) может выполнять запросы к единой БД через общий API. Или «плоская сеть» (Flat Network) — когда все микросервисы общаются без изоляции, и компрометация одного сервиса ведёт к компрометации всех.

Практические шаги

  • Threat modelling на старте — для каждого нового модуля составляйте модель угроз (STRIDE или PASTA)
  • Сегментация данных — разделяйте базы данных по уровню чувствительности: публичные и конфиденциальные данные храните отдельно
  • Проверка архитектуры — перед внедрением микросервисов проводите review по OWASP ASVS

5. Security Misconfiguration — настройки по умолчанию

Security Misconfiguration (некорректная конфигурация безопасности) — #1 по встречаемости. Включает: CORS-переопределения (Access-Control-Allow-Origin: *), открытые S3-бакеты, незащищённые отладочные точки входа, подробные сообщения об ошибках со стеком вызовов, пароли по умолчанию.

По данным Akamai, 83% протестированных облачных конфигураций содержат хотя бы одну критическую ошибку. Самое уязвимое место — Identity and Access Management (IAM): переопределённые роли, ненужные права для сервис-аккаунтов, устаревшие политики.

Чек-лист защиты

  • CORS — только белый список — никогда не используйте Access-Control-Allow-Origin: * в production
  • Аудит облачных конфигураций — регулярно проверяйте S3-бакеты, IAM-роли и разрешения сервис-аккаунтов
  • Отключение debug-режима — в production должны быть отключены все отладочные точки входа и подробные сообщения об ошибках
  • Безопасные пароли по умолчанию — все стандартные учётные записи меняйте при развёртывании

6. Vulnerable and Outdated Components — legacy-код

Vulnerable and Outdated Components (уязвимые компоненты) — проблема цепочки поставок. Каждое современное веб-приложение использует 300–500+ библиотек и фреймворков. Регулярно обновляются единицы.

Отчёт Snyk за 2025: 62% проектов содержат зависимости с известными CVE-уязвимостями. Среднее время устранения критической уязвимости — 78 дней. За это время злоумышленники успевают эксплуататировать уязвимость — в среднем $0,5 млн ущерба на один день задержки патча.

Что делать

  • SBOM (Software Bill of Materials) — ведите учёт всех зависимостей и их версий
  • Автоматические обновления — настройте Dependabot или Renovate для еженедельного обновления пакетов
  • Политика устаревания — установите срок устранения критических CVE не более 7 дней
  • Мониторинг уязвимостей — подключите Snyk или GitHub Advisory Database для оповещения о новых угрозах

7. Identification and Authentication Failures — недостаточная защита учётных записей

Identification and Authentication Failures (сбои идентификации) — слабые пароли, отсутствие MFA, недостаточная защита сессий, уязвимость к credential stuffing (атака с перебором учётных записей).

По данным Microsoft Digital Defense Report 2025: 921 атака в секунду — password attacks. MFA блокирует 99,9% автоматизированных атак. Тем не менее, 34% организаций из сектора SMB (малый и средний бизнес) до сих пор не используют двухфакторную аутентификацию для веб-приложений.

Чек-лист защиты

  • MFA для всех — внедрите двухфакторную аутентификацию на все критические точки входа
  • Политика паролей — требуйте минимум 12 символов и блокируйте учётную запись после 5 неудачных попыток
  • Защита сессий — устанавливайте таймаут сессии (15–30 минут бездействия), используйте httpOnly и Secure флаги для cookies
  • Rate limiting — ограничьте количество запросов на вход (не более 10 попыток в минуту с одного IP)

8. Software and Data Integrity Failures — supply chain

Software and Data Integrity Failures (нарушение целостности ПО и данных) — включает атаки через цепочку поставок: компрометация CI/CD-пайплайнов, неверифицированные обновления, использование неподписанных артефактов.

Громкий кейс: атака на SolarWinds (2020, но последствия — до 2026) показала, что один скомпрометированный build-сервер может внедрить backdoor в тысячи организаций. В 2025 году количество supply chain-атак выросло на 340% по сравнению с 2020.

Практические шаги

  • Подпись артефактов — все собираемые образы и пакеты должны быть подписаны (cosign, GPG)
  • Изоляция CI/CD — пайплайны сборки запускайте в изолированных окружениях с минимальными правами
  • Верификация обновлений — проверяйте контрольные суммы и подписи для всех сторонних зависимостей

9. Security Logging and Monitoring Failures — слепые зоны

Security Logging and Monitoring Failures (отсутствие мониторинга) — организации не видят атаку, проходящую мимо их систем. среднее время обнаружения (MTTD) в среднем по рынку — 96–117 дней для продвинутых целевых атакующих групп.

SIEM-системы не панацея: по данным IBM Cost of Data Breach 2025, наличие SIEM снижает время обнаружения на 42%, но не заменяет корректную настройку логирования. Ошибки: логирование без защиты от переполнения (log overflow), отсутствие мониторинга ошибок аутентификации, непродуманная политика хранения логов.

Чек-лист защиты

  • Логирование ключевых событий — фиксируйте все попытки входа, изменения прав, ошибки аутентификации
  • Защита от переполнения — настройте ротацию логов и ограничение на размер (logrotate, journald)
  • SIEM-правила — настройте корреляцию событий: 5+ ошибок аутентификации за минуту = оповещение
  • Хранение логов — установите срок хранения не менее 1 года для соответствия требованиям регуляторов

10. Server-Side Request Forgery (SSRF)

SSRF (подделка запросов на стороне сервера) — атака, при которой приложение по команде злоумышленника делает HTTP-запрос к внутренним ресурсам. Особенно опасна в облачных и microservices-архитектурах, где внутренние адреса метаданных облачных провайдеров (http://169.254.169.254/) позволяют получить IAM-ключи.

Самый резонансный случай 2025 года — атака на Capital One (2019) через SSRF, которая привела к утечке данных 100 млн клиентов — ущерб $300 млн. В 2025–2026 SSRF стабильно входит в топ-5 самых опасных уязвимостей по версии CWE.

Чек-лист защиты

  • Белый список доменов — разрешайте исходящие запросы только к доверенным адресам
  • Блокировка внутренних адресов — запретите запросы к частным IP (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254)
  • WAF-правила для SSRF — настройте блокировку запросов к внутренним адресам метаданных облачных провайдеров

Практические рекомендации: что внедрить в 2026 году

На основе анализа OWASP Top 10 — 2026, эксперты Positive Technologies, Akamai и OWASP Foundation сформулировали 5 ключевых направлений для защиты веб-приложений:

  1. Security by Design — внедрение threat modelling на этапе проектирования архитектуры. Каждая новая точка входа API проходит проверку на соответствие OWASP ASVS (Application Security Verification Standard).
  2. Автоматизация безопасности — SAST/DAST-сканирование в CI/CD-пайплайне (GitLab CI/CD, GitHub Actions). Пропуск билда при обнаружении критической уязвимости — обязательная практика.
  3. SBOM (Software Bill of Materials) — ведение учёта всех компонентов и их версий с автоматизированным оповещением о новых CVE. По данным OWASP, внедрение SBOM снижает время реакции на атаки с 78 до 12 дней.
  4. Web Application Firewall (WAF) — WAF нового поколения (с ML-детекцией аномалий в трафике) блокирует 99% массовых атак, включая SQL-инъекции, XSS и path traversal.
  5. Zero Trust Architecture — сегментация сети, микросегментация микросервисов, политика «никогда не доверяй, всегда проверяй» для каждого запроса между сервисами.
⚠ Что делать прямо сейчас:
  • Проверить, используют ли ваши веб-приложения HTTPS/TLS 1.3 — по OWASP, 34% ещё нет
  • Запустить автоматизированное сканирование зависимости (pip-audit, npm audit, safety)
  • Внедрить WAF с блокировкой SSRF-запросов к внутренним адресам метаданных облачных провайдеров
  • Проверить CORS-конфигурации — только белый список доверенных origin
Источник: OWASP Prevention Cheat Sheet, 2026.

📚 Читайте также

📖 Термины

OWASP · SQL-инъекция · WAF · Zero Trust · Пентест

🔗 Источники