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

Что такое OWASP Top 10

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

Это не стандарт и не полный чек-лист, а карта: она показывает, где ошибки встречаются чаще всего.

Десять категорий

A01. Нарушение контроля доступа

Пример: пользователь меняет в адресе /orders/1001 на /orders/1002 и видит чужой заказ. Сюда же относится SSRF — когда сервер можно заставить сделать запрос на внутренний адрес. Защита: проверять права на сервере в каждом запросе, по умолчанию запрещать всё.

A02. Ошибки конфигурации

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

A03. Сбои в цепочке поставок ПО

Пример: популярный npm-пакет взломали, и вредоносный код попал в вашу сборку. Защита: lock-файлы, проверка зависимостей на известные уязвимости, минимум лишних пакетов.

A04. Криптографические ошибки

Пример: сайт работает по HTTP, а пароли хранятся в MD5. Защита: HTTPS везде, современные алгоритмы, медленные хеши для паролей.

A05. Инъекции

Пример: SQL-инъекция через поле поиска или XSS через комментарий. Защита: параметризованные запросы и экранирование вывода по контексту.

A06. Небезопасный дизайн

Пример: промокод можно перебирать без ограничений, а восстановление пароля работает через угадываемый «секретный вопрос». Защита: продумывать сценарии злоупотреблений ещё на этапе проектирования (threat modeling).

A07. Ошибки аутентификации

Пример: форма входа не ограничивает число попыток, и злоумышленник подставляет утёкшие пары логин–пароль. Защита: rate limiting, 2FA, проверка паролей по спискам утёкших.

A08. Нарушение целостности ПО и данных

Пример: приложение скачивает обновления без проверки подписи или десериализует данные от пользователя. Защита: проверять подписи, защищать CI/CD, не доверять сериализованным объектам извне.

A09. Проблемы с логированием и оповещениями

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

A10. Неправильная обработка исключительных ситуаций

Пример: при ошибке сервис авторизации «пропускает» пользователя, а страница ошибки показывает стек вызовов и пути на сервере. Защита: при сбое закрывать доступ (fail closed), пользователю показывать общее сообщение, детали — только в логи.

Что проверить в первую очередь

Если времени мало, начните с этого:

1. Права доступа: может ли пользователь получить чужие данные, подставив другой ID?
2. Настройки продакшена: отключена ли отладка, сменены ли пароли по умолчанию, закрыты ли служебные панели?
3. Зависимости: запустите npm audit, pip-audit или аналог для вашего стека.
4. Ввод данных: все ли запросы к базе параметризованы?
5. Вход: есть ли ограничение попыток и 2FA для администраторов?
6. HTTPS и хранение паролей.

Частые ошибки

• Считать, что фреймворк «сам всё защищает». Он закрывает часть рисков, но не проверяет бизнес-логику.
• Проверять права только в интерфейсе: скрытая кнопка не мешает отправить запрос напрямую.
• Разово пройти чек-лист и забыть. Безопасность — регулярный процесс.