OWASP Top 10 2025: Новая эра безопасности приложений

Представьте: вы строите дом в районе, где время от времени случаются землетрясения, ураганы и наводнения. Было бы глупо не изучить статистику стихийных бедствий за последние годы, верно? Вы бы узнали, какие угрозы самые частые, какие — самые разрушительные, и как лучше защитить свой дом.

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

Каждый день миллионы приложений обрабатывают наши персональные данные, финансовые транзакции, медицинские записи. И каждый день кто-то пытается это взломать. Не из-за личной неприязни к вам, а потому что данные — это нефть XXI века, и злоумышленники хотят свою долю.

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

Игнорировать OWASP Top 10 — всё равно что строить дом из спичек в зоне лесных пожаров. Можно, конечно, но зачем?

OWASP: Некоммерческие стражи цифровой безопасности

История и миссия

OWASP (Open Worldwide Application Security Project) — это глобальная некоммерческая организация, которая с самого своего основания следует простой, но амбициозной миссии: сделать безопасность программного обеспечения видимой, понятной и доступной для всех.

9 сентября 2001 года — дата, которую стоит запомнить. Именно в этот день Марк Кёрфи (Mark Curphey) запустил проект OWASP. Среди первых лидеров были также Деннис Гроувз (Dennis Groves) и Джеремия Гроссман (Jeremiah Grossman). Начиналось всё скромно: группа энтузиастов хотела систематизировать знания о безопасности веб-приложений, которые на тот момент были разрозненны и хаотичны.

К 2004 году проект вырос настолько, что потребовалось его юридическое оформление — так появилась некоммерческая OWASP Foundation в США. В 2011 году было зарегистрировано европейское подразделение OWASP Europe VZW. А в феврале 2023 года совет директоров принял символичное решение: переименовать «Open Web» в «Open Worldwide» — подчеркнув, что организация давно вышла за рамки только веб-приложений и охватывает всю планету.

Сегодня масштаб впечатляет: около 42,000 волонтёров по всему миру и всего 8 штатных сотрудников. Да, вы не ослышались — организация с бюджетом 2,3 миллиона долларов (данные за 2017 год) работает почти полностью на волонтёрских началах. Членство в OWASP демократично: 50 долларов в год для индивидуальных участников (95 долларов за два года), 20 долларов для студентов, 500 долларов за пожизненное членство. Для стран с низким уровнем дохода действует тариф в 40% от стандартного — барьеры для входа минимальны.

В отличие от коммерческих вендоров, которые продают средства защиты, или консалтинговых компаний, которые продают услуги, OWASP существует исключительно за счёт волонтёров и пожертвований. Почти все участники — от членов совета до лидеров проектов — работают безвозмездно. Это даёт организации уникальную независимость: здесь нет скрытых коммерческих интересов, нет давления спонсоров, нет повестки вендоров.

Результат? Беспристрастные, основанные на реальных данных рекомендации, которым доверяют разработчики, архитекторы безопасности и регуляторы по всему миру.

Экосистема OWASP

OWASP — это не только список «Топ-10». Это огромная экосистема бесплатных инструментов, стандартов, исследований и образовательных материалов:

Главные проекты организации:

• OWASP ZAP (Zed Attack Proxy) — мощный сканер безопасности, который автоматически проверяет веб-приложения на уязвимости;
• WebGoat — намеренно уязвимое учебное приложение, где можно безопасно практиковаться во взломе и защите;
• ASVS (стандарт проверки безопасности приложений) — набор требований для оценки защищённости программ;
• SAMM (модель зрелости безопасности ПО) — помогает оценить и улучшить практики безопасной разработки в компании;
• Dependency-Check — инструмент для автоматического анализа используемых библиотек на известные уязвимости;
• учебные платформы: Juice Shop, WebGoat, DVWA — намеренно уязвимые приложения для тренировки навыков безопасности;
• шпаргалки по безопасности: сотни кратких руководств по безопасной разработке на все случаи жизни;
• местные сообщества: отделения OWASP работают в сотнях городов по всему миру, проводя встречи, конференции и мастер-классы;
• главные события: серия конференций Global AppSec (теперь называемых по регионам — Global AppSec USA, EU, Asia), а также тематические встречи экспертов Project Summits, где разрабатываются новые стандарты и обновляются существующие.

Организацией руководит исполнительный директор Эндрю ван дер Сток (Andrew van der Stock) вместе с командой руководителей программ и технологий. Но сила OWASP — в её волонтёрах. В 2024 году организация ввела правило: все лидеры глав, проектов и мероприятий обязаны иметь членство — это обеспечивает вовлечённость и ответственность.

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

OWASP Top 10: Эволюция главного рейтинга

Первый OWASP Top 10 появился в 2003 году как попытка систематизировать хаос уязвимостей веб-приложений. С тех пор список обновляется каждые 3-4 года, становясь всё более методологически зрелым и основанным на данных.

Таймлайн эволюции:

• 2003 — первая публикация, список критичных рисков веб-приложений;
• 2004, 2007 — регулярные обновления, отражающие изменения ландшафта угроз;
• 2010 — важная веха: впервые риски расставлены по величине риска, а не просто по частоте встречаемости;
• 2013 — продолжение эволюции методологии;
• 2017 — революция: включены категории по результатам отраслевого опроса (например, Insufficient Logging & Monitoring), которые автоматические тесты почти не фиксируют. Проанализировано 114,000+ приложений и опрошено 516 экспертов.
• 2021 — переход к анализу ~400 CWE с фокусом на первопричины, а не симптомы. Добавлены Insecure Design, Software & Data Integrity Failures и SSRF. Методология окончательно становится «основанной на данных» — сочетание больших данных и экспертного мнения.
• 2025 RC1 — две новые категории (Software Supply Chain Failures, Mishandling of Exceptional Conditions), SSRF консолидирован в Broken Access Control.

Интересные факты из истории:

🔥 Injection — ветеран списка: эта категория присутствует во всех версиях с 2003 года, что делает её самой долгоживущей угрозой в Top 10. SQL Injection был проблемой 20 лет назад, остаётся проблемой сегодня, и, похоже, будет проблемой ещё долго.

📊 100% поражение: в 2025 году категория Broken Access Control показала потрясающую статистику — 100% протестированных приложений имели хотя бы одно нарушение контроля доступа. Это не опечатка — абсолютно все приложения!

🎯 Голос сообщества имеет значение: категория Logging & Monitoring Failures впервые вошла в список в 2017 году исключительно благодаря голосованию практиков, несмотря на то что автоматические тесты её почти не обнаруживали. Это яркий пример того, как экспертное мнение помогает выявлять «невидимые» угрозы.

🔄 Эволюция SSRF: Server-Side Request Forgery впервые попала в Top 10 в 2021 году благодаря голосам экспертов, а в 2025 году была объединена с Broken Access Control — признак зрелости методологии, которая группирует атаки по классу последствий, а не по технике.

Методология «основанная на данных» работает так:

1. Сбор данных. OWASP получает миллионы результатов тестирования от коммерческих компаний, консультантов по безопасности, платформ поиска уязвимостей и команд безопасности крупных организаций.
2. Анализ частоты и последствий. Для каждой категории уязвимостей подсчитывается, как часто она встречается (процент приложений с проблемой), сколько случаев обнаружено, насколько сложно её использовать злоумышленникам и какой ущерб она может нанести.
3. Объединение данных. Восемь категорий выбираются на основе формулы риска (частота случаев × последствия).
4. Голосование сообщества. Ещё две категории добавляются на основе опроса практиков, чтобы учесть угрозы, которые пока сложно проверить автоматически (например, проблемы архитектуры или недостаточное ведение журналов событий).

Эта гибридная модель позволяет балансировать между объективными метриками и экспертным мнением, не упуская ни массовых проблем, ни тонких, но критичных угроз.

Влияние на индустрию: от Microsoft до стандартов

За годы Top 10 стал стандартом де-факто в индустрии. Вот как его используют:

Корпорации-гиганты:

• Microsoft встроил OWASP Top 10 в официальный модуль «Guide to Secure .NET Development», где разработчиков учат распознавать и предотвращать каждую категорию угроз;
• AWS публикует whitepaper «Use AWS WAF to Mitigate OWASP’s Top 10», предлагает готовый CloudFormation-шаблон с правилами защиты и проводит обучающие вебинары;
• Salesforce требует от партнёров понимать OWASP Top 10 перед размещением в AppExchange и связывает риски с инструментами (Code Analyzer, Retire.js).

Регуляторы и стандарты:

• PCI DSS Requirement 6.5 называет OWASP Guide одним из обязательных источников для обучения разработчиков безопасному кодингу;
• MITRE, DISA-STIG, FTC цитируют Top 10, делая его фактически «общим языком» индустрии;
• GDPR, HIPAA косвенно опираются на практики, описанные в OWASP.

Образование: университеты и сертификационные программы (CEH, OSCP, CISSP) изучают Top 10 как базу.

Это не просто список — это lingua franca безопасности приложений.

OWASP Top 10 2025 RC1: Что изменилось?

6 ноября 2025 года команда OWASP опубликовала релиз-кандидат восьмой редакции Top 10. Это предварительная версия, открытая для обратной связи сообщества до 20 ноября 2025, после чего выйдет финальная редакция.

Ключевые факты нового списка

• 2,8 миллиона результатов тестирования от коммерческих компаний, консультантов и платформ поиска уязвимостей;
• 589 типов уязвимостей проанализированы и объединены в 10 категорий на базе 248 подтипов;
• два новых риска: A03 «Уязвимости в цепочке поставок ПО» и A10 «Неправильная обработка ошибок»;
• SSRF больше не отдельная категория: подделка запросов на стороне сервера теперь включена в A01 «Нарушения контроля доступа».

Изменения в рейтинге: 2025 vs 2021

Главные тренды 2025

1. Уязвимости в цепочке поставок вышли на первый план: после серии громких взломов (SolarWinds, Log4Shell, event-stream NPM) специалисты по безопасности поняли, что атаки через стороннее программное обеспечение и библиотеки стали одной из главных угроз.
2. Ошибки в настройках — новая лазейка для злоумышленников: облачные технологии дали огромные возможности, но одновременно открыли новые уязвимости — незащищённые хранилища данных, секретные ключи доступа в переменных окружения и стандартные пароли, оставленные по умолчанию.
3. От абстрактного «плохого кода» к конкретным проблемам: вместо расплывчатого понятия «низкое качество кода» теперь выделяют конкретные уязвимости вроде «неправильной обработки ошибок», которые можно проверить и устранить.

Детальный разбор OWASP Top 10 2025 RC1

🔴 A01: Broken Access Control — Вечный лидер

Позиция: #1 в 2025 (был #1 в 2021)

Метрики

• 3,74% приложений поражены;
• 1,84 миллиона срабатываний;
• 40 CWE (включая теперь SSRF).

Суть проблемы

Контроль доступа — это проверка «а можно ли этому пользователю делать это действие над этим ресурсом?» Нарушение контроля доступа — это когда проверки нет, она неполная или её можно обойти.

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

• прямое обращение к объектам (IDOR): изменить номер заказа в адресной строке и получить доступ к чужим данным

  /api/orders/12345 → /api/orders/12346
  

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

Почему #1?

Broken Access Control (нарушения контроля доступа) — это самая распространённая категория уязвимостей по общему количеству случаев. В каждом приложении есть десятки или даже сотни точек, где проверяется, может ли пользователь выполнить то или иное действие. Достаточно допустить ошибку хотя бы в одной из них.

Кроме того, в версии Top10-2025 сюда добавили ещё один тип атак — SSRF (подделка запросов на стороне сервера). Это атака, при которой злоумышленник заставляет сервер отправлять запросы туда, куда не следует — например, к внутренним настройкам облачной инфраструктуры или закрытым системам компании.

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

1. По умолчанию всё запрещено: пользователь не может ничего делать, пока ему явно не дадут разрешение.
2. Единая система проверки прав: вместо проверок, разбросанных по всему коду (типа if (user.role === ‘admin’)), создать одно централизованное место для контроля доступа.
3. Проверка на стороне сервера: никогда не полагаться на данные, приходящие от пользователя.
4. Запись всех отказов в доступе: каждая попытка получить доступ к запрещённым данным должна фиксироваться в логах.
5. Ограничение частоты запросов: замедлить возможность перебора идентификаторов объектов.
6. Временные токены с возможностью отзыва: токены доступа с коротким сроком действия и механизмом их принудительной отмены при необходимости.

Примеры в реальном мире

• Facebook (2018): утечка токенов доступа 50 миллионов пользователей через уязвимость в функции «View As»;
• Parler (2021): все посты с геотегами скачаны через IDOR в API из-за последовательных ID.

🔧 A02: Security Misconfiguration — Тихий убийца

Позиция: #2 в 2025 (был #5 в 2021) ⬆️ +3

Метрики

• 3,00% приложений поражены;
• 719 084 случаев;
• 16 CWE;
• 100% приложений проверяются на этот риск.

Суть проблемы

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

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

• стандартные пароли: admin/admin, root/toor — те, что установлены по умолчанию;
• открытые облачные хранилища: например, хранилище Amazon S3, доступное всем желающим;
• слишком подробные сообщения об ошибках: показывают внутреннее устройство системы — запросы к базе данных, пути к файлам на сервере;
• ненужные сервисы: открытые сетевые порты и неиспользуемые точки входа в систему;
• отсутствие защитных заголовков: специальных настроек безопасности в ответах сервера;
• устаревшие версии: забытые компоненты системы с известными уязвимостями.

Почему взлетел на #2?

Инфраструктура как код (Terraform, CloudFormation, Kubernetes манифесты) сделала конфигурацию программируемой. Это хорошо для автоматизации, но плохо для безопасности: одна ошибка в шаблоне размножается на сотни инстансов.

Примеры:

• AWS S3: компании регулярно оставляют бакеты открытыми (Uber, Accenture, NSA, Republican National Committee);
• Kubernetes: дефолтные конфигурации часто оставляют API Server и Dashboard без авторизации;
• Docker: образы с незапатченными CVE публикуются в реестры.

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

1. Инфраструктура как код с автоматической защитой: шаблоны настройки систем должны быть безопасными изначально.
2. Автоматическая проверка настроек при развёртывании: использовать инструменты вроде Checkov, tfsec, kube-bench для поиска ошибок в конфигурации.
3. Принцип минимализма: удалять всё неиспользуемое — сервисы, открытые порты, лишние библиотеки.
4. Регулярные проверки безопасности: автоматические проверки прав доступа к ресурсам (например, с помощью AWS Access Analyzer).
5. Единые стандарты настройки: не давать командам разработчиков настраивать инфраструктуру по-своему, использовать общие проверенные шаблоны.

Примеры в реальном мире

• Capital One (2019): взлом через неправильно настроенный AWS WAF, 100 миллионов записей клиентов украдены;
• Elasticsearch (постоянно): тысячи открытых инстансов с индексируемыми данными из-за дефолтной конфигурации без авторизации.

⛓️ A03: Уязвимости в цепочке поставок ПО — Новая угроза эпохи зависимостей

Позиция: #3 в 2025 (был #6 в 2021 как «Уязвимые компоненты») ⬆️ +3

Метрики

• 5,19% приложений поражены (самый высокий показатель!);
• 215 000 инцидентов;
• 5 типов уязвимостей;
• всего 11 зарегистрированных уязвимостей — отражает сложность обнаружения.

Суть проблемы

Современное приложение — это не цельный блок, который вы написали сами. Это айсберг зависимостей:

• готовые пакеты кода, которые зависят от других пакетов, которые зависят от других пакетов…;
• образы контейнеров, собранные неизвестно кем;
• плагины для редакторов кода, расширения браузеров, инструменты для автоматизации;
• сторонние сервисы, виджеты, скрипты аналитики.

Каждая зависимость — это доверие. А что если:

• разработчик пакета продал его злоумышленникам? (event-stream в NPM, 2018);
• в библиотеку внедрили «чёрный ход»? (SolarWinds, 2020);
• уязвимость в системе логирования позволяет выполнить произвольный код? (Log4Shell, 2021);
• опечатка в названии: вместо requests установили requsets? (постоянная проблема в репозиториях кода).

Почему взлетел на #3?

Сообщество поставило Supply Chain #1 в опросе. Почему?

1. Атаки на цепочку поставок — это «1 → N»: взломав один пакет, злоумышленник компрометирует тысячи приложений.
2. Трудно обнаружить: антивирусы и сканеры не видят проблем в легитимном коде, который просто делает что-то нехорошее.
3. Транзитивные зависимости: вы знаете, что зависите от express, но знаете ли, что express зависит от 50 других пакетов?
4. CI/CD как вектор атаки: GitHub Actions, Jenkins плагины, Docker Hub образы — всё это точки входа.

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

1. Ведите спецификацию состава ПО (SBOM). Знайте, какие компоненты используются в вашем приложении. Инструменты: Syft, CycloneDX, SPDX.
2. Сканируйте зависимости. Используйте инструменты автоматической проверки (Dependabot, Snyk, Renovate).
3. Проверяйте целостность компонентов:
   • файлы фиксации версий (package-lock.json, yarn.lock);
   • проверка целостности подресурсов для скриптов, загружаемых со сторонних серверов;
   • цифровые подписи собранных компонентов.
4. Защищайте систему непрерывной интеграции:
   • двухфакторная авторизация для доступа к системам сборки;
   • хранение секретов в защищённых хранилищах (не в переменных окружения);
   • одноразовые окружения для сборки.
5. Мониторьте поведение приложений. Используйте системы обнаружения аномалий в работе программ.

Примеры в реальном мире

• SolarWinds Orion (2020): классика жанра — злоумышленники внедрили вредоносный код прямо в CI/CD цепочку компании, создав бэкдор в обновлении. Результат: компрометация 18,000+ организаций, включая Microsoft, FireEye, министерства США. Этот инцидент изменил индустрию и напрямую привёл к созданию OWASP Top 10 CI/CD Security Risks в 2022 году.
• Codecov bash uploader (2021): компрометация популярного инструмента покрытия кода в CI/CD привела к утечке секретов и учётных данных сотен компаний. Ещё один триггер для создания Top 10 CI/CD;
• event-stream NPM (2018): разработчик популярного пакета с 2 миллионами скачиваний в неделю передал права злоумышленникам, которые добавили код для кражи биткоин-кошельков;
• Dependency confusion атаки (2021): исследователь безопасности продемонстрировал, как можно загрузить вредоносные пакеты в публичные репозитории с именами, совпадающими с внутренними пакетами компаний — пакеты автоматически устанавливались в Apple, Microsoft, Netflix.

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

🔐 A04: Cryptographic Failures — Когда секреты перестают быть секретами

Позиция: #4 в 2025 (был #2 в 2021) ⬇️ -2

Метрики

• 3,80% приложений поражены
• 1,67 миллиона случаев
• 32 CWE

Суть проблемы

Данные могут находиться в одном из трёх состояний: в покое (at rest), в пути (in transit) и в использовании (in use). Cryptographic Failures — это когда данные, которые должны быть зашифрованы, передаются или хранятся в открытом виде, либо шифруются неправильно.

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

• HTTP вместо HTTPS: пароли, токены, личные данные в открытом виде;
• слабые алгоритмы: MD5, SHA1, DES, RC4 — давно взломаны;
• hardcoded ключи: ключ шифрования прямо в коде;
• слабая генерация случайности: использование Math.random() для токенов;
• игнорирование сертификатов: отключение проверки SSL/TLS;
• хранение паролей в открытом виде или с MD5: вместо Argon2, bcrypt, scrypt;
• отсутствие Perfect Forward Secrecy (PFS) — защиты старых сессий при компрометации ключа. Обычно, если злоумышленник украдёт секретный ключ сервера, он сможет расшифровать все ранее перехваченные зашифрованные сообщения. Perfect Forward Secrecy — это технология, которая не позволяет этого сделать: даже при краже ключа старые сессии остаются защищёнными.

Почему опустился на #4?

Не потому, что стало меньше проблем, а потому что A02 (Misconfiguration) и A03 (Supply Chain) выросли быстрее. Тем не менее, 1,67 млн случаев — это огромная цифра.

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

1. HTTPS везде: Let’s Encrypt сделал это бесплатным и простым.
2. HSTS (HTTP Strict Transport Security): форсировать HTTPS на уровне браузера.
3. TLS 1.2+ или 1.3: отключить TLS 1.0/1.1.
4. Современные алгоритмы:
   • хэширование паролей: Argon2, bcrypt, scrypt (с солью!);
   • симметричное шифрование: AES-256-GCM;
   • асимметричное: RSA 2048+, ECC.
5. Key Management:
   • Hardware Security Modules (HSM) или облачные KMS (AWS KMS, Azure Key Vault);
   • ротация ключей;
   • никогда не хардкодить ключи;
6. Подготовка к Post-Quantum Cryptography (PQC): NIST уже стандартизировал квантово-устойчивые алгоритмы.

Примеры в реальном мире

• Adobe (2013): 153 миллиона записей пользователей, пароли зашифрованы слабым 3DES в ECB режиме (легко атаковать);
• LinkedIn (2012): 6,5 миллионов паролей украдены, хранились как SHA1 без соли.

💉 A05: Инъекции — Классика, которая не умирает

Позиция: #5 в 2025 (был #3 в 2021) ⬇️ -2

Метрики

• 3,08% приложений поражены;
• 1,40 миллиона случаев;
• 62 445 зарегистрированных уязвимостей (лидер по количеству!);
• 37 типов уязвимостей.

Суть проблемы

Инъекция — это когда данные от пользователя интерпретируются как команды. Злоумышленник вставляет команды в запрос к базе данных, системную команду, запрос к каталогу, парсер XML, или даже запрос к языковой модели.

Типы Injection:

• SQL Injection: самый известный

  SELECT * FROM users WHERE username = 'admin' OR '1'='1' -- '
  

• NoSQL Injection: MongoDB, CouchDB
• OS Command Injection: выполнение shell-команд

  system("ping " + userInput) // userInput = "8.8.8.8; rm -rf /"
  

• LDAP Injection, XPath Injection, XML Injection
• XSS (Cross-Site Scripting): инжект JavaScript в HTML

  <script>alert(document.cookie)</script>
  

• LLM Prompt Injection: манипуляция поведением языковой модели

Почему опустился на #5?

62 445 CVE — это феноменально много. Но относительная распространённость ниже, чем у Access Control или Misconfiguration. Почему?

1. Зрелые фреймворки: Rails, Django, Spring автоматически параметризуют запросы.
2. ORM: вместо сырого SQL — Hibernate, Sequelize, SQLAlchemy.
3. Инструменты SAST/DAST: находят SQL Injection довольно эффективно.
4. Awareness: все знают про '; DROP TABLE users;-- благодаря мемам.

Но! XSS всё ещё лидирует внутри категории Injection.

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

1. Параметризация запросов (prepared statements):

   -- НЕ ТАК:
   "SELECT * FROM users WHERE id = " + userId
   
   -- А ВОТ ТАК:
   PreparedStatement ps = connection.prepareStatement("SELECT * FROM users WHERE id = ?");
   ps.setInt(1, userId);
   

2. ORM: использовать проверенные библиотеки.
3. Позитивная валидация (whitelist): разрешать только ожидаемые символы.
4. Экранирование вывода: для предотвращения XSS.
5. Минимальные привилегии БД: приложение не должно подключаться к БД с правами admin.
6. WAF (Web Application Firewall): дополнительный слой защиты.
7. Content Security Policy (CSP): ограничение источников JavaScript.

Примеры в реальном мире

• Heartland Payment Systems (2008): SQL Injection, 130 миллионов кредитных карт украдены;
• Sony Pictures (2011): SQL Injection, 1 миллион аккаунтов украдены, данные опубликованы в открытом доступе.

🧠 A06: Insecure Design — Когда проблема в самой идее

Позиция: #6 в 2025 (был #4 в 2021) ⬇️ -2

Метрики

• 1,86% приложений поражены;
• 730 000 случаев;
• 39 CWE.

Суть проблемы

Небезопасный дизайн — это не ошибка в коде, это ошибка в архитектуре. Даже идеально реализованный дизайн будет уязвимым, если сам дизайн небезопасен.

Примеры:

• отсутствие ограничения частоты запросов: можно перебрать все пин-коды или пароли;
• бизнес-логика без защиты:
  • купон на скидку можно применить многократно;
  • можно перевести отрицательную сумму и получить деньги;
• отсутствие изоляции данных разных клиентов: компания A видит данные компании B;
• игнорирование моделирования угроз: не рассмотрены сценарии атак на стадии проектирования.

Почему опустился на #6?

Организации инвестируют в безопасную разработку, моделирование угроз и обучение команд. Это работает! Но проблемы цепочки поставок и неправильных настроек росли быстрее, поэтому небезопасный дизайн сместился вниз.

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

1. Моделирование угроз. Анализировать возможные атаки на ранних стадиях проектирования (методики: STRIDE, PASTA, деревья атак).
2. Проверенные шаблоны безопасности. Использовать готовые решения вместо изобретения велосипеда (например, стандарт OWASP SAMM).
3. Требования безопасности в задачах. Включать защиту в планирование как обычные функции.
4. Эшелонированная защита. Не полагаться на один слой обороны — строить несколько уровней защиты.
5. Принцип минимальных привилегий. По умолчанию давать только необходимые права.
6. Изоляция. Разделять обязанности сотрудников и данные разных клиентов.

🔑 A07: Authentication Failures — Кто ты на самом деле?

Позиция: #7 в 2025 (был #7 в 2021) 🔄 Стабильно

Метрики

• 2,92% приложений поражены;
• 1,12 миллиона случаев;
• 36 CWE.

Суть проблемы

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

Типичные проблемы:

• подбор украденных паролей: использование паролей из других утечек (люди используют одинаковые пароли на разных сайтах);
• перебор паролей: атака возможна при отсутствии ограничения частоты попыток;
• слабые пароли: admin/admin, password123;
• отсутствие или слабая многофакторная проверка: коды по SMS легко перехватить (подмена SIM-карты);
• кража или подмена сессии: злоумышленник крадёт идентификатор сессии пользователя;
• пароли прямо в коде: учётные данные зашиты в исходный код или настройки.

Почему стабилен на позиции 7?

Фреймворки и сервисы аутентификации (Okta, Auth0, Azure AD) сделали проверку личности стандартизированной. Но атаки всё равно происходят, особенно через социальную инженерию и фишинг.

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

1. Многофакторная проверка по умолчанию. Предпочтительно аппаратные токены (YubiKey) или приложения для генерации кодов (не SMS!).
2. Проверка паролей по спискам утечек. Использовать базы вроде Have I Been Pwned API.
3. Ограничение частоты попыток и капча. Защита от перебора паролей.
4. Безопасные сессии:
   • защита cookie от кражи через JavaScript (флаги HttpOnly и Secure);
   • короткое время жизни сессии;
   • перевыпуск идентификатора сессии после входа.
5. Одинаковые ответы на неверные попытки входа. Не говорить «пользователь не найден» или «неверный пароль» — давать общее сообщение.
6. Менеджеры паролей. Поощрять использование для создания уникальных сложных паролей.

🛡️ A08: Software or Data Integrity Failures — Доверяй, но проверяй

Позиция: #8 в 2025 (был #8 в 2021) 🔄 Стабильно

Метрики

• 2,75% приложений поражены;
• 501 000 случаев;
• 14 CWE.

Суть проблемы

Это про доверие к коду и данным без проверки. Разница с A03 (цепочка поставок): A03 — это про зависимости и инструменты, A08 — про локальную целостность.

Примеры:

• неподписанные обновления: приложение скачивает обновление по незащищённому каналу и запускает без проверки;
• сторонний JavaScript: подключение скриптов с внешних серверов без проверки целостности;
• небезопасное восстановление объектов: приложение восстанавливает объекты из данных без проверки, что позволяет выполнить произвольный код;
• система сборки без защиты: любой может отправить код в главную ветку и развернуть его на боевом сервере.

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

1. Цифровые подписи. Все артефакты (обновления, пакеты) должны быть подписаны.
2. Проверка целостности внешних скриптов:

   <script src="https://cdn.example.com/lib.js"
           integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
           crossorigin="anonymous"></script>
   

3. Изоляция системы сборки. Защита веток, обязательная проверка кода, многофакторная аутентификация.
4. Не доверять восстановлению объектов. Использовать безопасные форматы (JSON) и проверять данные перед обработкой.

📊 A09: Logging & Alerting Failures

Позиция: #9 в 2025 (был #9 в 2021) 🔄 Стабильно

Метрики

• 3,91% приложений с проблемами логирования;
• 260 000 случаев;
• 5 CWE.

Суть проблемы

Без логов вы не увидите атаку. Без оповещений вы не узнаете об инциденте. Без аудита вы не восстановите, что произошло.

Проблемы:

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

Почему держится на позиции 9?

Голосование сообщества. Автоматические тесты плохо покрывают наблюдаемость, но бизнес-ущерб от отсутствия логов огромен: вы не знаете, что вас взломали, пока не становится слишком поздно.

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

1. Логировать всё важное:
   • аутентификация (успех и неудача);
   • попытки доступа (в том числе отказы);
   • изменения данных и настроек;
   • ошибки проверки входных данных.
2. Единые форматы. JSON и структурированные логи для автоматической обработки.
3. Защита целостности. Логи должны быть только для записи, с отправкой в централизованную систему сбора.
4. Ловушки для обнаружения атак. Специальные приманки (фальшивые токены, ссылки), срабатывание которых сигнализирует о взломе.
5. Автоматические оповещения. Настроить триггеры на подозрительные события с готовыми инструкциями для реагирования.
6. НЕ логировать секреты. Пароли, токены, ключи API, персональные данные (или маскировать их).

⚠️ A10: Mishandling of Exceptional Conditions — Новичок в списке

Позиция: #10 в 2025 (новый!) ✨

Метрики

• 2,95% приложений поражены;
• 770 000 случаев;
• 24 CWE.

Суть проблемы

Это новая категория, призванная заменить расплывчатое «плохое качество кода». Фокус: как приложение обрабатывает ошибки и исключения.

Проблемы:

• необработанные исключения: приложение падает, раскрывая технические детали и внутреннее устройство;
• отказ с открытием доступа: при ошибке система разрешает действие вместо того, чтобы его запретить;
• подробные сообщения об ошибках: «SQL error: table ‘users’ not found at /var/www/app/db.php:42»;
• исчерпание ресурсов: отсутствие лимитов приводит к отказу в обслуживании;
• некорректная обработка граничных случаев: деление на ноль, обращение к пустым значениям, переполнение буфера.

Почему добавлен?

OWASP хотел конкретики вместо «просто пишите хороший код». Неправильную обработку ошибок можно тестировать, измерять и исправлять.

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

1. Отказ с блокировкой доступа. При ошибке запрещать действие, а не разрешать его.
2. Единая инфраструктура обработки исключений. Централизованный обработчик ошибок для всего приложения.
3. Откат транзакций. При ошибке откатывать изменения, чтобы сохранить целостность данных.
4. Лимиты ресурсов. Таймауты, ограничения размера запроса и частоты обращений.
5. Мониторинг ошибок. Отслеживать повторяющиеся ошибки — это может быть признаком атаки или бага.
6. Безопасные сообщения об ошибках. Пользователю — общее сообщение, в логи — подробности.

За пределами веб-приложений: Семейство OWASP Top 10

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

📱 OWASP Mobile Top 10 (2014 → 2024)

История: Первая версия вышла в 2014 году, последняя — в 2024 году. За 10 лет мобильная разработка прошла путь от «веба в обёртке» до сложнейших нативных приложений с биометрией, криптокошельками и интеграцией с устройствами интернета вещей.

Что нового в 2024:

• M2: недостаточная безопасность цепочки поставок — новая категория, отражающая проблемы с библиотеками разработки, сторонними компонентами и зависимостями;
• усиленное внимание к приватности в эпоху GDPR и CCPA;
• в 2024 году на OWASP Project Summit собрались десятки экспертов, и только координация NowSecure привела к 40+ запросам на изменение для обновления стандарта.

Топ-10 рисков 2024:

• M1: неправильное использование учётных данных — хранение токенов в незашифрованном виде на устройстве;
• M2: недостаточная безопасность цепочки поставок — зависимости и библиотеки разработки (новое!);
• M3: небезопасная аутентификация и авторизация;
• M4: недостаточная проверка входных и выходных данных;
• M5: небезопасная передача данных — HTTP вместо HTTPS, отсутствие привязки сертификатов;
• M6: недостаточный контроль приватности — утечка персональных данных через аналитику и трекеры;
• M7: недостаточная защита бинарников — отсутствие обфускации, легко провести обратную разработку;
• M8: неправильная настройка безопасности;
• M9: небезопасное хранение данных — чувствительные данные в базе или настройках без шифрования;
• M10: недостаточная криптография — слабые алгоритмы, ключи прямо в коде.

Зачем отдельный список? Мобильные приложения работают в недоверенной среде (устройство пользователя под его полным контролем), имеют ограниченные ресурсы, зависят от системных функций (iOS/Android), часто работают без сети и хранят данные локально.

🔌 OWASP API Security Top 10 (2019 → 2023)

История: Первая версия вышла в 2019 году, последняя — в 2023 году. API стали основой современной архитектуры (микросервисы, SPA, mobile-first), но с этим пришли специфические риски.

API — это скрытая поверхность атаки. Пользователь не видит API напрямую, но они обрабатывают критичные данные. В отличие от веб-интерфейсов, API часто менее защищены: разработчики думают «это же внутреннее», а оно уже давно доступно из интернета.

Топ-10 рисков API 2023:

• API1: нарушение авторизации на уровне объектов — получение чужих данных через изменение номера в запросе;
• API2: нарушение аутентификации — слабые токены, отсутствие ограничения частоты, подбор украденных паролей;
• API3: нарушение авторизации на уровне свойств — изменение полей, которые должны быть только для чтения (например, is_admin=true);
• API4: неограниченное потребление ресурсов — отсутствие лимитов ведёт к отказу в обслуживании и исчерпанию бюджета облака;
• API5: нарушение авторизации на уровне функций — обычный пользователь вызывает административные методы;
• API6: неограниченный доступ к бизнес-процессам — автоматизация действий ботами (скупка билетов, накрутка рейтингов);
• API7: подделка запросов на стороне сервера;
• API8: неправильная настройка безопасности — разрешение запросов с любых сайтов, подробные ошибки, стандартные пароли;
• API9: неправильное управление версиями — забытые старые версии API, устаревшая документация;
• API10: небезопасное использование сторонних API — доверие внешним API без проверки.

Интересный факт: три из пяти топ-рисков связаны с авторизацией (API1, API3, API5). API — это про контроль доступа в чистом виде. Фокус на «человеческих» бизнес-функциях (API6) — уникальная черта списка.

🤖 OWASP Top 10 for Large Language Model Applications (2023 → 2025)

История: Проект стартовал в 2023 году как реакция на взрывной рост LLM-приложений (ChatGPT, GPT-4, Claude, LLaMA). В марте 2025 года проект получил статус Flagship — высшую категорию признания в OWASP, наравне с оригинальным Top 10 и ZAP.

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

Топ-10 рисков для приложений на языковых моделях:

• LLM01: инъекция в промпт — манипуляция поведением модели через вредоносные запросы (прямые или косвенные через данные);
• LLM02: небезопасная обработка вывода — модель генерирует вредоносный код (XSS, SQL-инъекции, команды shell);
• LLM03: отравление обучающих данных — вредоносные данные в обучающей выборке влияют на поведение модели;
• LLM04: отказ в обслуживании модели — дорогие запросы исчерпывают ресурсы и бюджет;
• LLM05: уязвимости цепочки поставок — зависимости, предобученные модели, наборы данных, плагины;
• LLM06: раскрытие чувствительной информации — модель раскрывает персональные данные из обучающей выборки или запросов;
• LLM07: небезопасный дизайн плагинов — расширения с произвольным кодом, недостаточная проверка входов и выходов;
• LLM08: чрезмерные полномочия — модель получает слишком много прав (доступ к файлам, выполнение команд, вызовы API);
• LLM09: чрезмерное доверие — слепое доверие выводу модели без проверки, автоматизация критичных решений;
• LLM10: кража модели — извлечение весов модели через API.

Почему это важно? Языковые модели — это совершенно новый класс уязвимостей, для которого традиционные подходы не работают:

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

☁️ OWASP Cloud-Native Application Security Top 10 (2019 → 2022)

История: Первая версия — 2019 год, последнее обновление контента — 2022 год. Проект помогает командам по безопасности разработки закрывать ошибки в контейнерах, сервисных сетках, программируемой инфраструктуре и Kubernetes.

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

Специфические риски облачных приложений:

• неправильные политики доступа (например, полный доступ ко всем ресурсам хранилища);
• секреты в переменных окружения контейнеров;
• необновлённые образы контейнеров с известными уязвимостями;
• отсутствие сегментации сети в Kubernetes;
• повышение привилегий через систему управления доступом;
• публичные API без ограничения частоты запросов — счёт за облако улетает в стратосферу.

🚀 OWASP Top 10 CI/CD Security Risks (2022)

История: Опубликован в 2022 году как прямая реакция на инциденты SolarWinds, Codecov, подмену зависимостей и другие атаки на цепочку разработки. Проект показал, что системы автоматизации — это не просто инструмент разработки, это критичная граница безопасности.

Системы автоматической сборки и развёртывания — это ключи от королевства. Если злоумышленник скомпрометирует Jenkins, GitHub Actions или GitLab CI, он получает:

• возможность внедрить бэкдоры в код;
• доступ к секретам (ключи API, учётные данные, токены доступа);
• право развернуть вредоносные артефакты на боевых серверах;
• историю коммитов, архитектуру, внутреннюю документацию.

Топ-10 рисков систем автоматизации:

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

🌐 Другие специализированные Top 10: краткий обзор

🖥️ Desktop App Security (безопасность настольных приложений) Top 10 (2021 → 2023) Для разработчиков толстых клиентов (Electron, Qt, WinForms). Фокус на инъекции, защиту бинарных файлов (обфускация, защита от отладки), хранение данных локально. Данные по уязвимостям обновлены до 2023 года.

⚙️ Low-Code/No-Code Top 10 (2023) Для «гражданских разработчиков» на платформах типа OutSystems, Mendix, PowerApps. Предупреждает о рисках учётных записей, инъекциях через формы, неправильной настройке прав доступа.

🧪 Безопасность машинного обучения Top 10 (2023, черновик v0.3) Покрывает атаки на системы машинного обучения: манипуляция входными данными, отравление данных, кража моделей, внедрение бэкдоров. Пока в статусе черновика.

🐳 Docker Top 10 (в разработке, черновик) Набор из 10 контролей безопасности для Docker и контейнеров. Проект пока готовит первый релиз.

🌐 Client-Side Security (безопасность клиентской части) Top 10 (2022, кандидат) Для команд разработки одностраничных приложений: атаки через манипуляцию DOM, контроль источников, несанкционированные изменения скриптов, уязвимости обмена сообщениями.

🔒 Приватность Top 10 (2014 → 2021, v2.0) Чек-лист организационных и технических рисков приватности. Актуален в эпоху GDPR и CCPA.

⚡ Serverless Top 10 (2017) Показывает, как традиционные риски (инъекции, уязвимые компоненты) проявляются в бессерверных функциях (AWS Lambda, Azure Functions). Специфика: событийная архитектура, холодные старты, привязка к поставщику.

🌍 Интернет вещей Top 10 (2014/2018) Для производителей устройств: слабые пароли, небезопасный механизм обновлений, отсутствие управления устройствами. Фокус на прошивку, физический доступ, долгоживущие устройства.

☸️ Kubernetes Top 10 (2022, обновление в работе на 2025) Приоритизирует риски кластеров: небезопасные настройки рабочих нагрузок, уязвимости цепочки поставок, неправильная настройка управления доступом, открытый API-сервер.

Философия семейства Top 10: «Единого решения для всех не существует». Каждая технология, платформа и архитектурный паттерн имеют свои уникальные векторы атак. Разработчик мобильного приложения должен думать о других угрозах, чем инженер серверной части на Kubernetes, который работает с другими рисками, чем специалист по языковым моделям.

Заключение: Что дальше?

OWASP Top 10 2025 RC1 — это моментальный снимок текущего состояния безопасности. Но угрозы эволюционируют быстрее, чем обновляются списки.

Ключевые выводы

1. Цепочка поставок — это новая реальность. Вы не контролируете зависимости, но вы ответственны за их использование.
2. Настройка = код. Программируемая инфраструктура делает ошибки масштабируемыми, но также делает безопасность автоматизируемой.
3. Контроль доступа всё ещё №1. Несмотря на все инструменты и фреймворки, ошибки авторизации остаются самой массовой проблемой.
4. Наблюдаемость критична. Без журналов событий и оповещений вы не увидите атаку, пока не станет слишком поздно.
5. Безопасность с самого начала. Защита должна быть встроена в архитектуру, код, тесты и процесс сборки — не добавлена в конце.

Что делать прямо сейчас?

1. Прочитайте полный OWASP Top 10 2025 RC1. Когда выйдет финальная версия, изучите её подробно.
2. Проведите анализ проблем. Определите, какие риски из списка актуальны для вашего приложения.
3. Интегрируйте инструменты в процесс непрерывной интеграции:
   • статический анализ кода: SonarQube, Semgrep, CodeQL;
   • динамическое тестирование: OWASP ZAP, Burp Suite;
   • анализ зависимостей: Dependabot, Snyk, Trivy.
4. Обучите команду. Используйте OWASP Juice Shop и WebGoat для практики.
5. Моделируйте угрозы. Проанализируйте возможные сценарии атак на вашу архитектуру.
6. Назначьте лидеров безопасности. Определите «евангелистов безопасности» в каждой команде.

Финальная мысль

OWASP Top 10 — это не чеклист, который можно просто «закрыть». Это живой документ, отражающий текущее состояние войны между защитниками и атакующими.

Безопасность — это не состояние, это процесс. Не цель, а путь. Не проект, а культура.

И помните: лучшая защита — это понимание угроз. OWASP Top 10 даёт вам карту минного поля. Теперь ваша задача — научиться по нему ходить.

Источники и полезные ссылки

• OWASP Top 10 2025 RC1
• OWASP Main Site
• OWASP API Security Top 10
• OWASP Mobile Top 10
• OWASP LLM Top 10
• OWASP Cheat Sheet Series
• OWASP ZAP (сканер)
• OWASP Juice Shop