OWASP Top 10 в 2026: что изменилось и как от этого защищаться

Почему обычный пересказ OWASP не работает

Линейный пересказ OWASP Top 10 от A01 до A10 — это самый частый способ написать статью про AppSec и одновременно самый бесполезный. Конкурентов с такой структурой десятки, разработчик читает не три раза, а ни разу, потому что список не отвечает на главный вопрос — что закрывать первым именно в моём приложении.

Эта статья построена иначе. Сначала разбираем, как класс приложения определяет, какие категории OWASP доминируют в его поверхности атаки. Дальше идём не по списку, а по типовым векторам защиты — авторизация, криптография, инъекции, supply chain, наблюдаемость — с конкретными параметрами, примерами кода и ссылками на работающие референсные стандарты.

Матрица: класс приложения × доминирующие категории OWASP

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

| Класс приложения | Доминирующие категории | Что закрывать первым | |---|---|---| | SaaS B2B (multi-tenant) | A01 Broken Access Control, A04 Insecure Design, A09 Logging | Строгая модель авторизации с tenant-isolation; единый PEP на каждом эндпойнте | | Финтех / платежи | A02 Cryptographic Failures, A07 Auth Failures, A10 SSRF | Криптография по PCI DSS и NIST SP 800-63B; строгая MFA на критичных операциях | | Госуслуги / 152-ФЗ | A01, A09, A05 Misconfiguration | Логирование событий безопасности под Приказ № 21 ФСТЭК; access control с регулярным пересмотром прав | | Промышленный портал / B2B-портал к ERP | A06 Vulnerable Components, A08 Integrity Failures, A03 Injection | Контроль зависимостей через SCA в CI; параметризованные запросы во всех слоях ORM | | API-first продукт | A03 Injection, A10 SSRF, A07 Auth Failures | Schema validation на входе; контроль исходящих запросов из приложения |

Если ваш продукт попадает в несколько категорий — закрывайте пересечения. Финтех-SaaS должен закрыть и тенант-изоляцию (A01), и платёжную криптографию (A02).

Авторизация: что отличает работающую модель от теневой

Большая часть инцидентов в SaaS — это не баги в коде, а ошибки в проекте авторизации. Сигналы, которые отличают зрелую модель.

PEP на каждом эндпойнте. Точка контроля доступа находится не в UI и не на уровне маршрутизатора, а в самом контроллере, который принимает запрос. В идеале — через декоратор / middleware, который при отсутствии явного правила доступа отказывает по умолчанию.

Проверка владения объектом, а не только роли. Самая частая ошибка в SaaS — проверка user.role === 'admin', но не object.tenantId === user.tenantId. Атакующий с любой ролью одного тенанта может попасть к данным другого через прямой запрос ID.

Непредсказуемые идентификаторы. UUIDv7 или ULID вместо инкрементальных целочисленных ID. Это не защита от broken access control сама по себе, но снижает энтропию для перебора.

Тесты на авторизацию отдельно от функциональных. В CI должен быть набор тестов вида «попробовать дотянуться до чужого ресурса с разными ролями» — генерируется автоматически из openapi-схемы.

Подробный разбор того, как мы проверяем авторизацию в пентесте, есть в посте «Что такое пентест простыми словами». Там же — какие красные флаги в финальном отчёте говорят, что подрядчик не проверил авторизацию должным образом.

Криптография: конкретные параметры вместо общих слов

A02 проваливают не от незнания, а от выбора параметров «по умолчанию». Цифры на 2026 год.

Хеширование паролей. Argon2id — стандарт де-факто. Параметры по RFC 9106 для интерактивных сценариев на серверах среднего класса:

- memory = 64 MB (m=65536) - iterations = 3 (t=3) - parallelism = 4 (p=4)

Если argon2 недоступен в вашем стеке, bcrypt с cost factor 12 на 2026 год даёт ~250 ms на хеш на стандартном серверном CPU — приемлемо для interactive-сценариев.

Симметричное шифрование. Только AEAD-режимы: AES-256-GCM или ChaCha20-Poly1305. AES-CBC без HMAC — это в 2026 году аудиторский finding на любой проверке. Хранение ключей — HSM или secret manager (HashiCorp Vault, AWS KMS, Yandex Lockbox), никогда в коде или конфигурации.

TLS. Минимум TLS 1.2, но в 2026 году разумный baseline — TLS 1.3-only. Отказ от TLS 1.0/1.1 уже давно стандарт, но в индустриальных приложениях иногда находим до сих пор.

Управление ключами. Ротация раз в 90 дней для access-ключей, раз в год для подписей. Принципиальная вещь — каждый ключ должен быть в реестре с владельцем, датой создания и плановой датой ротации.

Инъекции: один паттерн на все классы

A03 решён архитектурно уже двадцать лет, но продолжает встречаться, потому что вместо архитектурного решения команды по-прежнему опираются на «не забывать экранировать».

Универсальный паттерн — параметризованные операции. Любое взаимодействие с внешним интерпретатором (БД, shell, шаблонизатор, LDAP, XPath) идёт через структурированный API, не через конкатенацию строк.

Плохо: python cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

Хорошо: python cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

То же в shell:

Плохо: os.system(f"convert {filename} out.png") — пользователь подставляет ; rm -rf /.

Хорошо: subprocess.run(["convert", filename, "out.png"], check=True) — аргументы передаются массивом, без shell-интерпретации.

Поймать оставшиеся места можно SAST в CI. Минимум — Semgrep с правилами под ваш стек, плюс DAST для приложений с UI. Для Node/Python/Go бесплатные правила Semgrep ловят 80% типовых случаев конкатенации SQL за один прогон.

Supply chain: SCA не опционален

A06 в современной разработке — это не «забытая старая библиотека», а активный фронт. Случаи компрометации npm-пакетов через захват аккаунта мейнтейнера, malicious-зависимости в PyPI и rubygems публикуются каждый месяц.

Минимум для любой команды:

- SCA в CI с блокировкой релизов при критичных CVE. Trivy, Grype, Snyk — выбор зависит от стека и бюджета. - SBOM в формате CycloneDX или SPDX для каждого артефакта, который попадает в продакшн. - Запрет на установку зависимостей без lockfile (npm, pip, cargo, go modules). - Изоляция CI runners от продакшн-секретов.

Подробности по защите контейнерных пайплайнов есть в посте «Безопасность Kubernetes: типичные ошибки» — там же раздел про подпись образов через cosign и admission control по результатам сканирования.

Аутентификация и сессии

A07 закрывается набором известных мер, но конкретика на 2026 год важна.

Пароли. Минимум 12 символов, без обязательной композиции (заглавная + цифра + спецсимвол). Проверка против списка скомпрометированных паролей при регистрации и смене.

MFA. TOTP (RFC 6238) для большинства сценариев, WebAuthn / FIDO2 для критичных. SMS — не считается фактором в 2026 году, есть слишком много кейсов SIM-swap.

Сессии. Короткий access token (15–30 минут) + refresh token (от 24 часов до 30 дней в зависимости от приложения). Refresh token обязательно с rotation и detection повторного использования.

Защита от brute force. Rate limiting на уровне эндпойнта аутентификации (5 попыток в 5 минут на IP + 10 попыток в час на учётку), временные блокировки, мониторинг аномалий через SIEM.

Insecure design и SSRF: что меняется в облачной архитектуре

A04 и A10 закрываются на этапе проектирования, а не патчем.

Insecure design — это threat modeling до того, как написана первая строчка кода. Минимальная модель: STRIDE или LINDDUN для приватных данных. На каждый новый сервис или существенное изменение архитектуры — короткая сессия threat modeling с фиксацией решений.

SSRF в облаке опаснее, чем в on-prem, из-за instance metadata service. AWS — 169.254.169.254, Azure — 169.254.169.254, GCP — metadata.google.internal. Без IMDSv2 / token-based доступа атакующий через SSRF получает credentials машины и из них доступ ко всему, что ей разрешено.

Защита.

- Whitelist целевых адресов для исходящих запросов приложения. - Запрет приватных диапазонов: 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local 169.254.0.0/16. - IMDSv2 в AWS, Workload Identity в GCP, Managed Identity в Azure. - Изоляция исходящего трафика приложения через прокси с фильтрацией.

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

Наблюдаемость как часть AppSec

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

Что должно логироваться на каждом приложении:

- Все события аутентификации (успех / отказ / блокировка). - Изменения прав доступа. - Доступ к чувствительным данным (личные данные, платёжная информация). - Административные операции. - Исходящие запросы во внешние системы. - Ошибки авторизации (попытки доступа к чужому ресурсу).

Что должно происходить с логами:

- Структурированный формат (JSON Lines или OTEL формат). - Централизованное хранение в SIEM (Elastic, Splunk, MaxPatrol SIEM). - Правила корреляции под сценарии, релевантные приложению, а не дефолтные. - Хранение минимум 90 дней (для соответствия большинству регуляторных требований — 12 месяцев). - Защита от модификации (append-only, write-once хранилище).

Подключение приложения к корпоративному SOC и выбор между SOC и MDR — отдельная большая тема, разобранная в посте «SOC или MDR: как выбрать и не переплатить».

Сводная дорожная карта

Если в вашей команде нет систематического подхода к OWASP Top 10, начните с минимального плана на 90 дней.

Недели 1–2. Запустите SCA в CI с блокировкой релиза при критичных CVE. Это самая быстрая мера — занимает один спринт, закрывает A06.

Недели 3–4. Проведите ручной аудит топ-5 наиболее критичных эндпойнтов API на broken access control. Сфокусируйтесь на IDOR и проверке владения объектом. Это закрывает наиболее опасную часть A01.

Месяц 2. Внедрите централизованное логирование событий безопасности и интеграцию с SIEM (даже минимальный Elastic стек подойдёт). Закрывает A09 и подготавливает почву для проверок регулятора.

Месяц 3. Threat modeling по STRIDE на одном-двух наиболее критичных сервисах. Это закладывает культуру и закрывает корневую причину A04.

После 90 дней — оценка по OWASP ASVS на уровень 1 (или 2 для приложений с чувствительными данными), и из неё уже точечная программа на следующие 6 месяцев.

Если нужна помощь

Мы проводим экспресс-аудит приложений на соответствие OWASP Top 10 с конкретным отчётом по матрице из этой статьи. Длится 2–3 недели, на выходе — список приоритизированных уязвимостей с PoC, рекомендуемые меры защиты и дорожная карта на 90 дней.