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

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

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

Что такое OWASP Top 10 и почему на него ориентируются?

OWASP Top 10 — это рейтинг рисков безопасности веб-приложений от некоммерческого проекта Open Worldwide Application Security Project. Список обновляется раз в несколько лет; в версии 2025 года, по данным самого OWASP, использованы результаты тестирования более 2,8 миллиона приложений от 13 организаций.

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

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

Какие уязвимости входят в OWASP Top 10:2025?

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

№	Категория	Простыми словами
A01	Broken Access Control	Пользователь видит или меняет чужие данные
A02	Security Misconfiguration	Небезопасные настройки сервера, фреймворка или облака
A03	Software Supply Chain Failures	Уязвимые или подменённые зависимости и инструменты сборки
A04	Cryptographic Failures	Данные хранятся или передаются без надёжного шифрования
A05	Injection	Ввод пользователя выполняется как код: SQL-инъекции, XSS
A06	Insecure Design	Уязвимость заложена в саму логику, а не в код
A07	Authentication Failures	Слабые пароли, подбор, утечки сессий
A08	Software or Data Integrity Failures	Система доверяет данным и обновлениям без проверки
A09	Security Logging and Alerting Failures	Атаку никто не заметил, потому что нет логов и оповещений
A10	Mishandling of Exceptional Conditions	Ошибки обработаны так, что система открывается или падает

Как выглядят эти уязвимости на практике?

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

Контроль доступа и инъекции

Контроль доступа нарушен, когда сервер проверяет, что пользователь вошёл, но не проверяет, что запрошенный объект принадлежит ему. Классический пример — заказ по адресу /orders/1042: поменяли число на 1043 и увидели чужой заказ.

// Уязвимо: найдёт любой заказ по номеру
$order = Order::findOrFail($id);

// Безопасно: ищем только среди заказов текущего пользователя
$order = $request->user()->orders()->findOrFail($id);

Инъекция возникает, когда данные пользователя попадают в запрос к базе или в HTML как есть. Современные фреймворки защищают по умолчанию — параметризованными запросами и экранированием, — поэтому инъекции чаще всего появляются там, где разработчик обошёл защиту «сырым» запросом.

Фото: Unsplash

Настройки, зависимости и ошибки

• Неправильная конфигурация — включённый режим отладки на продакшене, открытое хранилище файлов, стандартные пароли в админке.
• Цепочка поставок — библиотека с известной уязвимостью или вредоносный пакет с похожим названием. Защита — автоматическая проверка зависимостей в CI и фиксированные версии.
• Обработка исключительных ситуаций — например, сбой проверки прав, после которого код по ошибке пропускает запрос дальше, или сообщение об ошибке, в котором видны пути и запросы к базе.

Что спросить у подрядчика о безопасности?

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

Вопросы, которые мы советуем задать:

1. Как проверяется, что пользователь имеет доступ именно к этому объекту? Есть ли на это тесты?
2. Как отслеживаются уязвимости в зависимостях? Что происходит, когда находят критичную?
3. Где хранятся секреты — ключи, пароли к базе, токены сервисов?
4. Как хранятся пароли пользователей и какие данные шифруются?
5. Какие события безопасности логируются и кто получает оповещения?
6. Проводился ли внешний аудит или тест на проникновение перед запуском?

Если на вопросы звучат общие фразы вроде «у нас всё защищено» — это сигнал, что безопасность держится на удаче.

Как встроить безопасность в процесс разработки?

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

Минимальный набор для продукта любого размера:

• проверка зависимостей на известные уязвимости в CI — например, composer audit или npm audit;
• статический анализ кода и поиск секретов в репозитории;
• тесты на контроль доступа для ключевых сценариев;
• код-ревью с отдельным вниманием к авторизации и работе с вводом;
• обновление фреймворка и библиотек по расписанию, а не «когда будет время»;
• логи входов, смены прав и ошибок доступа с оповещениями.

# Шаг в CI: сборка падает, если в зависимостях есть известная уязвимость
- name: Audit dependencies
  run: |
    composer audit
    npm audit --audit-level=high

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

Коротко

• OWASP Top 10:2025 — актуальный список главных рисков веб-приложений, удобный как чек-лист для бизнеса.
• Самая частая проблема — контроль доступа: пользователь получает чужие данные.
• Новые категории 2025 года — цепочка поставок ПО и обработка исключительных ситуаций.
• Спрашивайте подрядчика, как закрыт каждый пункт, и просите показать это в коде и CI.
• Безопасность — часть процесса: автоматические проверки на каждое изменение, а не разовый аудит.