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

OWASP Top 10 — список самых критичных уязвимостей веб-приложений, обновляемый каждые 3–4 года международной некоммерческой организацией OWASP (Open Worldwide Application Security Project). Документ стал индустриальным стандартом: на нём строятся курсы безопасности, требования к разработчикам, политики compliance, чеклисты pentest’ов. Без понимания OWASP Top 10 невозможно писать безопасный код в 2026 году.

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

Что такое OWASP Top 10

OWASP Top 10 — список из 10 категорий уязвимостей, наиболее часто встречающихся и наиболее опасных в веб-приложениях. Список формируется на основе анализа тысяч реальных приложений по всему миру, с учётом частоты эксплуатации, потенциального ущерба и сложности обнаружения.

Документ обновляется каждые 3–4 года. Действующая редакция датируется 2021 годом; обновление до версии 2025 находится в активной разработке и ожидается к концу 2025–2026 года с учётом новых угроз: AI-prompt injection, supply chain attacks, vulnerabilities в LLM-приложениях.

OWASP Top 10 — не исчерпывающий список всех угроз, а priority guide. Помимо него существуют: OWASP Mobile Top 10 (для мобильных приложений), OWASP API Security Top 10 (для API), OWASP LLM Top 10 (для AI-приложений), и десятки других специализированных документов.

A01:2021 — Broken Access Control

Главная угроза по версии 2021 года. Возникает, когда пользователь может выполнять действия или получать доступ к данным, которые ему не должны быть доступны.

Типичные сценарии

• Изменение параметра в URL: /api/orders/123 → /api/orders/124, получение чужого заказа
• Прямой доступ к admin-endpoint через знание URL
• Privilege escalation: обычный пользователь получает права администратора
• Отсутствие проверки авторизации в JWT при изменении user_id
• CORS-настройки, разрешающие неавторизованные кросс-доменные запросы

Защита

• Принцип deny by default: доступ запрещён, если явно не разрешён
• Проверка авторизации на сервере для каждого ресурса, не только в UI
• Использование непредсказуемых идентификаторов (UUID вместо последовательных ID)
• Логирование попыток несанкционированного доступа
• Регулярные access control audits через automated и manual тестирование

A02:2021 — Cryptographic Failures

В прошлой редакции называлось «Sensitive Data Exposure». Касается всех аспектов работы с чувствительными данными и криптографией: пароли, токены, персональные данные, финансовая информация.

Типичные сценарии

• Хранение паролей в открытом виде или в слабом хеше (MD5, SHA-1)
• Передача данных по HTTP вместо HTTPS
• Использование устаревших протоколов TLS (SSL 3.0, TLS 1.0)
• Жёстко закодированные секреты в коде или конфигах
• Слабые алгоритмы шифрования (DES, RC4)
• Использование статических salts или предсказуемых IV

Защита

• Хранение паролей через bcrypt, scrypt, Argon2 (с правильными параметрами)
• HTTPS на всех страницах, HSTS-заголовок
• TLS 1.2+ только (предпочтительно TLS 1.3)
• Современные алгоритмы шифрования: AES-256, ChaCha20-Poly1305
• Secrets management через HashiCorp Vault, AWS Secrets Manager
• Регулярная ротация ключей
• Шифрование чувствительных данных at rest

A03:2021 — Injection

SQL injection, NoSQL injection, OS command injection, LDAP injection. Возникает, когда пользовательский ввод вставляется в команды или запросы без правильного экранирования.

Классический пример SQL injection

// Уязвимый код:
query = "SELECT * FROM users WHERE name = '" + userInput + "'";

// Атака: userInput = "' OR '1'='1"
// Результат: вернёт всех пользователей

Защита

• Prepared statements / parameterized queries. Главный способ защиты.
• ORM. Современные ORM (Sequelize, Prisma, SQLAlchemy, Hibernate) делают это автоматически.
• Input validation. Whitelist-валидация — что разрешено, а не что запрещено.
• Stored procedures с параметрами. Для legacy-кода.
• Least privilege для DB-пользователя. Приложение не должно иметь DROP TABLE прав.
• WAF (Web Application Firewall) как дополнительный слой защиты.

A04:2021 — Insecure Design

Новая категория 2021 года. Касается фундаментальных проблем в дизайне приложения, не связанных с реализацией. Можно идеально написать код, но если архитектура небезопасна — все стены могут оказаться картонными.

Примеры insecure design

• Отсутствие rate limiting на чувствительных операциях (вход, сброс пароля)
• Бизнес-логика, позволяющая отрицательные значения в платежах
• Восстановление пароля через знание ответа на «секретный вопрос» с публичными ответами
• Отсутствие многофакторной аутентификации для admin-аккаунтов
• Отсутствие threat modeling на этапе проектирования

Защита

• Threat modeling на этапе дизайна (STRIDE, PASTA, OCTAVE)
• Secure design patterns (defense in depth, principle of least privilege)
• Reference architectures с проверенной безопасностью
• Security reviews для критических фич
• Использование стандартизированных решений (OAuth для auth, SSO) вместо собственных

A05:2021 — Security Misconfiguration

Неправильная конфигурация серверов, фреймворков, баз данных, облачной инфраструктуры. Часто результат «дефолтных» настроек, оставленных без изменения.

Типичные ошибки

• Default credentials (admin/admin, root/password)
• Включённые ненужные функции и порты
• Подробные сообщения об ошибках в production (stack traces)
• Open S3 buckets, незащищённые БД
• Устаревшие версии ПО с известными уязвимостями
• Отключённые security headers (HSTS, CSP, X-Frame-Options)
• Verbose error messages, раскрывающие внутренние детали

Защита

• Hardening guides для каждого компонента стека
• Infrastructure as Code с security-проверками
• Automated security scans (Trivy, Snyk, Tenable, Qualys)
• Минимизация attack surface (только нужные сервисы)
• Security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
• Регулярные patch management

A06:2021 — Vulnerable and Outdated Components

Использование библиотек, фреймворков, операционных систем с известными уязвимостями. Особенно опасно с supply chain attacks: вредоносный код в популярной зависимости.

Известные инциденты

• Log4Shell (CVE-2021-44228) — критическая уязвимость в Log4j, затронувшая миллионы приложений
• Heartbleed в OpenSSL
• Equifax data breach через уязвимость в Apache Struts
• SolarWinds supply chain attack
• Множественные npm-пакеты с malware (event-stream, ua-parser-js)

Защита

• Software Composition Analysis (SCA): Snyk, Dependabot, Renovate
• SBOM (Software Bill of Materials) для tracking всех зависимостей
• Регулярное обновление зависимостей (не ждать критических уязвимостей)
• Использование только проверенных репозиториев
• Подписи и верификация пакетов (sigstore, npm provenance)
• Vendoring критических зависимостей

A07:2021 — Identification and Authentication Failures

Проблемы с механизмами идентификации и аутентификации пользователей. Поднялась с A2 в 2017 до A7 в 2021 — означает, что отрасль научилась лучше с этим работать, но проблема всё ещё актуальна.

Типичные сценарии

• Permitting brute force attacks (нет rate limiting)
• Permitting weak passwords («12345», «password»)
• Plain text storage паролей
• Незащищённые механизмы восстановления пароля
• Session ID в URL
• Reusing session ID после авторизации
• Не invalidate session при logout

Защита

• Multi-factor authentication (MFA) обязательно для критических аккаунтов
• Rate limiting на login-endpoint
• Strong password policies (NIST 800-63B рекомендует passphrases вместо complexity)
• Password hashing через bcrypt/Argon2
• Secure session management (httpOnly, Secure, SameSite cookies)
• Session timeout и regeneration
• OAuth 2.0 / OpenID Connect для SSO
• Защита от credential stuffing (проверка через haveibeenpwned API)

A08:2021 — Software and Data Integrity Failures

Новая категория 2021. Касается доверия к данным и коду без должной верификации.

Примеры

• Подгрузка JS-библиотек с CDN без SRI (Subresource Integrity)
• Установка плагинов из непроверенных источников
• Auto-update без проверки подписи
• Insecure deserialization
• CI/CD pipelines без проверки целостности артефактов

Защита

• Digital signatures для всех артефактов
• Subresource Integrity (SRI) для внешних CDN
• Code signing для бинарных файлов
• Trusted package repositories
• Защита CI/CD pipeline’a от компрометации
• Использование supply chain security tools (Sigstore, in-toto)

A09:2021 — Security Logging and Monitoring Failures

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

Что должно логироваться

• Все попытки авторизации (успешные и неуспешные)
• Изменения привилегий и доступа
• Доступ к чувствительным данным
• Изменения конфигурации
• Платёжные транзакции
• Подозрительные паттерны (множественные попытки логина с одного IP)

Защита

• Централизованное логирование (Elasticsearch, Loki, Datadog, Splunk)
• SIEM-системы для корреляции событий
• Алерты на подозрительные паттерны
• Защита логов от tampering
• Удержание логов согласно compliance-требованиям
• Periodic security log review

A10:2021 — Server-Side Request Forgery (SSRF)

Уязвимость, при которой атакующий заставляет сервер делать запросы к внутренним или внешним ресурсам, к которым у атакующего нет прямого доступа.

Сценарий атаки

Приложение позволяет загружать изображения по URL: ?url=https://example.com/image.jpg

Атакующий передаёт: ?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS metadata service).

Сервер делает запрос внутри AWS-сети и возвращает атакующему AWS-credentials. Это была причина массивного Capital One breach в 2019 году.

Защита

• Whitelist разрешённых доменов для outbound-запросов
• Отключение redirects при необходимости
• Network segmentation: приложение не имеет доступа к metadata-сервисам
• Использование IMDSv2 в AWS (требует session token)
• Disable unused URL schemes (file://, gopher://, dict://)

OWASP Top 10 для LLM-приложений

В 2023 году OWASP выпустила отдельный список для AI-приложений, обновляемый в 2025 году. Топ-10 для LLM:

• LLM01: Prompt Injection. Манипуляция модели через специально сконструированный ввод.
• LLM02: Insecure Output Handling. Использование вывода LLM без валидации (например, выполнение SQL, сгенерированного моделью).
• LLM03: Training Data Poisoning. Загрязнение данных, на которых обучается модель.
• LLM04: Model Denial of Service. Перегрузка модели специально сконструированными запросами.
• LLM05: Supply Chain Vulnerabilities. Уязвимости в моделях, фреймворках, плагинах.
• LLM06: Sensitive Information Disclosure. Утечка конфиденциальных данных через ответы модели.
• LLM07: Insecure Plugin Design. Уязвимости в плагинах и инструментах, расширяющих LLM.
• LLM08: Excessive Agency. LLM с слишком широкими правами действий.
• LLM09: Overreliance. Чрезмерное доверие выводу LLM без верификации.
• LLM10: Model Theft. Кража или копирование модели через адаптацию через API.

С ростом использования AI этот список становится таким же критичным, как классический OWASP Top 10.

Инструменты для автоматизированной проверки

Большинство команд используют связку: SAST в IDE (для быстрой обратной связи), SCA в CI/CD (для зависимостей), DAST в staging (для дин. тестирования), runtime protection в production.

Типичные ошибки разработчиков

• Игнорирование security в спринтах. «Сначала фичи, потом безопасность» — типичный антипаттерн. Security-debt накапливается быстрее, чем разрешается.
• Полагание на «security by obscurity». Скрытие endpoint’ов вместо настоящей защиты. Любой обнаружится через автоматические сканеры.
• Custom crypto. Написание собственных алгоритмов шифрования или хеширования. Используйте проверенные библиотеки.
• Игнорирование security headers. CSP, HSTS, X-Frame-Options — простые в настройке, но недооцениваемые механизмы защиты.
• Privileged secrets в коде. API-ключи, токены, пароли в репозитории. Используйте secrets management.
• Слепое доверие input’у. «Это поле из нашей формы, безопасно». Атакующий может отправить что угодно.
• Отсутствие rate limiting. Это копеечная защита от brute-force и DoS, но многие забывают.
• Verbose error messages в production. Stack traces, SQL queries в ответах — подсказки для атакующего.
• Полагание только на WAF. Web Application Firewall — слой защиты, не замена secure coding.
• Игнорирование dependency updates. Запуск систем с библиотеками, в которых известные CVE.
• Отсутствие security training для разработчиков. Команды без понимания OWASP воспроизводят одни и те же уязвимости.
• «Security — это только pentest перед релизом». Security должна быть в каждом коммите, не разовым мероприятием.

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

Как часто проводить security-аудит?

Automated сканирование — каждый коммит. Manual security review — каждый крупный релиз. Внешний pentest — раз в год или при существенных архитектурных изменениях. Bug bounty — постоянно, если бюджет позволяет.

Достаточно ли пройти OWASP Top 10 для соответствия GDPR / PCI DSS / других compliance?

Нет. OWASP Top 10 — необходимый минимум, но не достаточный. Регуляторные требования содержат дополнительные специфические требования: data residency, breach notification, audit logging.

Как обучать команду по OWASP?

Платформы вроде OWASP WebGoat, Hack The Box, PortSwigger Web Security Academy дают практические упражнения. Regular code reviews с фокусом на security также эффективны. Annual security training — обязательный минимум.

Что делать, если обнаружили уязвимость в своём проекте?

Зависит от критичности. Критическая (RCE, утечка данных) — немедленный hotfix, уведомление пользователей. Средняя — фикс в следующем релизе. Низкая — backlog. Документируйте через CVE если уязвимость в open-source.

Помогает ли AI в обнаружении уязвимостей?

Помогает. Инструменты типа Snyk Code, Semgrep, GitHub Copilot Code Review используют ML для обнаружения паттернов уязвимостей. Не заменяют human review, но повышают coverage и скорость.

OWASP Top 10 покрывает мобильные приложения?

Не полностью. Для мобильных приложений существует отдельный OWASP Mobile Top 10 со специфическими угрозами: insecure storage, jailbreak-detection, certificate pinning.

Заключение

OWASP Top 10 — не «чеклист на пять минут», а карта основных территорий безопасности веб-приложений. Команды, которые систематически защищаются от каждой категории, исключают 90%+ типовых атак. Команды, игнорирующие документ, рано или поздно становятся новостью в техническом сообществе — и не в хорошем смысле. В 2026 году с ростом атак, AI-инструментов для эксплуатации уязвимостей, supply chain attacks дисциплинированная работа по OWASP Top 10 — не опция, а условие выживания серьёзного веб-проекта. Это базовая гигиена, которая должна быть встроена в процессы разработки, а не накладываться поверх готового кода.