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

Почти каждая громкая атака на веб-приложение связана не со сломанной криптографией уровня спецслужб или редким o-day, а вполне стандартными ошибками. Неправильно проверили права доступа, доверились пользовательскому вводу, оставили слабое место в цепочке поставки, не заметили аномалию в логах. OWASP Top 10 ценен именно этим: он не обещает исчерпывающую картину всех рисков, но очень точно показывает, где веб-приложения ломаются чаще всего и что стоит чинить в первую очередь.

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

Эта статья ориентирована на веб-разработчиков на Python, PHP, JavaScript и Java, AppSec-инженеров, тимлидов и CISO. Ниже разбираем все десять категорий OWASP Top 10:2025, показываем уязвимый и безопасный код там, где это уместно, привязываем каждую категорию к типовым сценариям атак, а в конце собираем практический чек-лист и рекомендации по WAF.

Что такое OWASP и почему Top 10 важен

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

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

Top 10 — его самый известный проект: на него ссылаются регуляторы и аудиторы, его закладывают в корпоративные security baseline, на него ориентируются разработчики, AppSec и архитекторы.

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

В этой статье разбираем редакцию OWASP Top 10:2025. Предыдущая была в 2021 году, и изменения заметные — просто механически переносить старую структуру нельзя. Часть категорий переименована и переставлена, SSRF как самостоятельный пункт исчез и теперь рассматривается в контексте архитектуры, доступа и обработки недоверенных входных данных. Появилась новая десятая категория про обработку исключительных состояний.

A01: Broken Access Control

Broken Access Control остаётся на первом месте и в версии 2025 года. Категория объединяет ошибки, при которых пользователь получает доступ к данным или операциям за пределами своих прав.

Инъекции команды уже научились искать автоматически, а ошибки контроля доступа чаще всего завязаны на бизнес-логику, роли, tenancy и нестандартные переходы между объектами. Именно поэтому они проходят и сканеры, и поверхностное ревью кода.

Примеры уязвимости

Самый частый сценарий — IDOR (Insecure Direct Object Reference): пользователь меняет ID в URL и получает чужие данные. Другая типичная ветка — privilege escalation, когда обычный пользователь вызывает административный endpoint, потому что проверку роли сделали только на фронтенде или только в одном из слоёв приложения.

Уязвимый код на Flask: python

@app.route('/order/<int:id>')
def get_order(id):
def get_order(id):
    return Order.query.get(id)  # нет проверки владельца

Как защититься

• Принцип deny by default: запрещено всё, что не разрешено явно.
• Все проверки прав — только на сервере, никогда на клиенте.
• Централизованная модель авторизации (RBAC или ABAC с policy engine, например Casbin или OPA).
• Публичные идентификаторы лучше делать UUID, а не последовательными int — тогда перебор по диапазону перестаёт работать как бесплатный инструмент атаки.

python

@app.route('/order/<uuid:id>')
@login_required
def get_order(id):
    order = Order.query.get_or_404(id)
    if order.user_id != current_user.id and not current_user.is_admin:
        abort(403)
    return order.to_json()

Подробности — OWASP Top 10:2025 A01.

A02: Security Misconfiguration

Security Misconfiguration поднялась на второе место. Сюда попадают ошибки настройки серверов, фреймворков, контейнеров, облачных сервисов и самого приложения, которые открывают атакующему лишние возможности.

Это одна из самых неприятных категорий, потому что здесь редко бывает одна большая уязвимость. Проблема обычно складывается из цепочки мелочей: включённый debug, дефолтный пароль, лишний HTTP-метод, открытая админка, слабые заголовки безопасности, публичный бакет, слишком широкие права сервисного аккаунта.

Типичный набор:

• дефолтные пароли admin/admin;
• включённый debug в production;
• стек-трейсы в ответах API;
• открытые служебные эндпоинты;
• лишние права у сервисных аккаунтов;
• незакрытые порты управления;
• отсутствие HSTS, CSP и других базовых защитных заголовков.

Как защититься

Нужен hardening по baseline (например, CIS Benchmarks), IaC с автоматическими проверками, отдельные конфигурации для dev и prod и принцип минимальной поверхности атаки. Конфигурацию нужно проверять в CI/CD так же регулярно, как код и зависимости.

Подробности — OWASP Top 10:2025 A02.

A03: Software Supply Chain Failures

Software Supply Chain Failures — одна из самых заметных тем в версии 2025 года. Категория описывает риски, которые приходят не из вашего исходного кода напрямую, а через зависимости, сборочные пайплайны, репозитории пакетов, плагины и механизмы доставки.

Современное веб-приложение почти никогда не существует само по себе: оно собирается из npm-, pip-, Maven-, Composer-зависимостей, контейнерных образов, GitHub Actions, внешних registries и промежуточных артефактов. Поэтому атака на supply chain нередко оказывается эффективнее, чем прямой взлом самого приложения.

Что сюда входит:

• устаревшие и уязвимые зависимости;
• компрометация пакета в публичном репозитории;
• подмена артефактов сборки;
• утечка секретов из CI;
• запуск небезопасных self-hosted runner'ов;
• отсутствие контроля происхождения образов и бинарников.

Как защититься

Ключевые меры:

• SCA-инструменты в CI/CD (Dependabot, Snyk, OWASP Dependency-Check, Trivy);
• SBOM для релизов;
• цифровые подписи артефактов;
• изолированные runner'ы и минимальные секреты в пайплайнах.

Регулярные обновления библиотек по-прежнему обязательны, но уже не закрывают категорию целиком.

Подробности — OWASP Top 10:2025 A03.

A04: Cryptographic Failures

Cryptographic Failures сместилась на четвёртое место, но сама проблема никуда не делась. Сюда входят ошибки шифрования и хранения чувствительных данных, из-за которых пароли, токены, ключи и персональные данные оказываются недостаточно защищены.

Типичные ошибки хорошо известны, но встречаются регулярно: plaintext-пароли в базе, MD5 или SHA-1 без соли, самописная криптография, хардкод секретов, HTTP вместо HTTPS, отключённая проверка сертификата, слабые cipher suites, устаревший TLS на legacy-эндпоинтах.

Как защититься

• Для паролей нужны адаптивные хеш-функции: bcrypt, scrypt, Argon2id.
• Транспортный уровень — TLS 1.2 как минимум, лучше 1.3, включённый HSTS, контроль сертификатов.
• Все секреты хранятся в отдельном secret manager, а не в исходниках и не в случайных env-переменных.
• Для данных at rest — шифрование проверенными библиотеками вместо самодельных схем.

python

import bcrypt

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

if bcrypt.checkpw(input_password.encode(), hashed):
    login_user(user)

Подробности — OWASP Top 10:2025 A04.

A05: Injection

Injection сохраняется в топе и в версии 2025 года. Атака возникает, когда приложение подставляет пользовательский ввод в SQL, команды ОС, шаблоны, LDAP или NoSQL-запросы без корректной изоляции данных от кода.

Картина привычная: SQL Injection, command injection, template injection, XSS как следствие небезопасной работы с недоверенным вводом. Масштаб последствий не меняется — одна непараметризованная строка в неправильном месте может дать утечку данных, обход аутентификации или полный RCE.

Пример уязвимого кода: python

query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)
php
$query = "SELECT * FROM users WHERE email = '" . $_GET['email'] . "'";
$result = mysqli_query($conn, $query);

Как защититься

Параметризованные запросы — единственный надёжный способ. Дополнительно: ORM с типобезопасными запросами, валидация по схеме, минимальные права учётной записи БД и WAF как второй эшелон, а не замена параметризации.

Исправленный код: python

cursor.execute(
    "SELECT * FROM users WHERE email = %s",
    (email,)
)
php
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = ?");
$stmt->execute([$_GET['email']]);
$user = $stmt->fetch();

Подробности — OWASP Top 10:2025 A05.

A06: Insecure Design

Insecure Design в 2025 году остаётся отдельной категорией, и это один из самых важных сигналов от OWASP. Проблема здесь не в баге реализации, а в устройстве самой фичи или системы.

Если восстановление пароля можно брутфорсить без rate limiting, если деньги переводятся без дополнительного подтверждения, если внутренние API доверяют всему трафику из своей сети, если модель доступа не учитывает multi-tenant-сценарий — это не «недосмотр разработчика в одном endpoint'е». Это архитектурный дефект, и локальными правками его не починить.

Как защититься

• Threat modeling на этапе проектирования (STRIDE, PASTA).
• abuse cases в требованиях.
• Secure design patterns.
• Обязательное архитектурное ревью для фич, которые затрагивают деньги, персональные данные и управление доступом.

Подробности — OWASP Top 10:2025 A06.

A07: Authentication Failures

Authentication Failures в версии 2025 сформулирована точнее, чем предыдущая категория про identification and authentication. Здесь фокус на том, как приложение подтверждает личность пользователя и насколько этот процесс устойчив к краже учётных данных, подбору, фиксации сессии и обходу дополнительных факторов. Типичные симптомы: слабые пароли без нормальной политики, отсутствие MFA, предсказуемые токены восстановления, слишком долгоживущие сессии, отсутствие защиты от credential stuffing, слабая логика password reset.

Как защититься

• MFA как базовый стандарт, passkeys и WebAuthn там, где это возможно.
• Проверка паролей на утечки.
• rate limiting с плавными задержками для логина и восстановления.
• Ротация session ID после аутентификациию
• Короткоживущие токены и понятная модель их отзыва.

Подробности — OWASP Top 10:2025 A07.

A08: Software and Data Integrity Failures

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

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

Как защититься

• подписи артефактов и обновлений;
• запрет опасной десериализации;
• ограничение доверия к плагинам и внешним источникам;
• жёсткая политика для того, что может исполняться или применяться автоматически.

Подробности — OWASP Top 10:2025 A08.

A09: Security Logging and Alerting Failures

В версии 2025 по сравнению с 2021 формулировка уточнилась: теперь это не просто logging and monitoring, а logging and alerting. Если команда не видит атаку вовремя, даже сравнительно локальный инцидент быстро перерастает в полноценный breach.

Как защититься

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

На практике это означает централизованное хранилище логов с защитой от подмены, интеграцию с SIEM и минимальный набор алертов: серия неудачных логинов, неожиданный доступ к admin-endpoint, всплеск ошибок 5xx, нетипичная активность от одного IP или учётной записи.

Подробности — OWASP Top 10:2025 A09.

A10: Mishandling of Exceptional Conditions

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

Она выглядит менее хакерски, чем SQL Injection, но именно такие состояния нередко дают путь к обходу проверок, утечке внутренних деталей, отказу в обслуживании или неконсистентному состоянию данных. Если приложение в ошибке возвращает stack trace, пропускает проверку, повторяет операцию бесконечно или сохраняет объект наполовину — это уже вопрос безопасности, а не только надёжности.

Как защититься

Нужны fail-safe defaults, аккуратная обработка исключений, таймауты и circuit breaker'ы, защита от бесконечных ретраев, идемпотентность критичных операций, маскирование внутренних ошибок во внешних ответах. Abuse-сценарии на деградацию зависимостей стоит закладывать при проектировании, а не проверять только на продакшен-инцидентах.

Подробности — OWASP Top 10:2025 A10.

WAF как первая линия защиты от OWASP Top 10

WAF (Web Application Firewall) фильтрует HTTP-трафик до приложения и закрывает часть категорий на сетевом уровне. Он не заменяет безопасный код и зрелые процессы, работает там, где угрозы хорошо распознаются по сигнатурам и аномалиям запросов.

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

Чек-лист: защита от OWASP Top 10

• Проверяйте права доступа на бэкенде для каждого запроса, не доверяйте проверкам на клиенте, используйте UUID для публичных идентификаторов (A01).
• Отключайте всё лишнее в конфигурации, разделяйте dev и prod, сканируйте IaC и конфиги автоматически (A02).
• Ведите учёт зависимостей, используйте SCA, собирайте SBOM, подписывайте артефакты и изолируйте CI/CD (A03).
• Храните пароли только в виде адаптивных хешей (bcrypt, scrypt, Argon2), включайте TLS 1.2+, держите секреты в secret manager (A04).
• Параметризуйте все SQL-запросы, не склеивайте команды из строк, валидируйте входные данные по схеме (A05).
• Проводите threat modeling и архитектурное ревью для фич, связанных с деньгами, доступом и персональными данными (A06).
• Включайте MFA, сокращайте срок жизни токенов, ротируйте session ID и защищайтесь от credential stuffing (A07).
• Проверяйте целостность обновлений и артефактов, ограничивайте доверие к плагинам и опасной десериализации (A08).
• Логируйте попытки входа, изменения прав, доступ к чувствительным данным, отправляйте события в SIEM (A09).
• Закладывайте fail-safe поведение на ошибках, ставьте таймауты и circuit breaker'ы, не показывайте пользователю внутренние детали падений (A10).
• Подключайте WAF как второй эшелон защиты, особенно против инъекций, ботов и сигнатурных атак.
• Встраивайте SAST, DAST и secrets scanning в CI/CD, а не переносите безопасность на этап после релиза.

Заключение

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

Если ресурсов мало, разумно начать с A01, A04 и A05: контроль доступа, криптография и инъекции по-прежнему дают самую прямую связь с реальными инцидентами. После этого стоит подтянуть A02 и A03, потому что misconfiguration и supply chain сегодня ломают прод не хуже классических багов. Дальше — выстраивать полноценный DevSecOps-контур: security review, SCA, WAF, SIEM, secret manager и нормальную работу с исключительными состояниями.