OWASP Top 10 (2021) — краткое руководство для разработчиков

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

Список описывает не конкретные виды уязвимостей, а их категории. В каждой категории — десятки записей CWE. Поэтому важно не заучить его, а применить к своему проекту: для каждого пункта спросите себя, «где это может быть у нас?».

Ниже кратко о каждом пункте редакции 2021 года: что это и что можно проверить уже сегодня.

A01. Broken Access Control — нарушение контроля доступа

Пользователь получает доступ к данным или действиям, которые ему не принадлежат. Классический пример: изменить /invoices/1042 на /invoices/1043 и увидеть счёт другого клиента (IDOR).

Проверьте: в каждом контроллере проверяется ли на сервере, что объект принадлежит текущему пользователю? В Laravel для этого есть Policy и authorize(). Просто спрятать кнопку в интерфейсе — не защита.

A02. Cryptographic Failures — криптографические ошибки

Передача и хранение секретных данных в открытом виде или под слабой защитой: вход по HTTP, хеширование паролей через MD5, незашифрованные резервные копии.

Проверьте: весь сайт работает по HTTPS и включён HSTS; пароли хешируются через bcrypt или argon2; старые TLS 1.0/1.1 отключены.

A03. Injection — инъекции

Пользовательский ввод напрямую попадает в запрос или команду: SQL, команды ОС, а также XSS (в редакции 2021 года XSS включён в эту категорию).

Проверьте: есть ли в сыром SQL DB::raw() или склейка строк; есть ли в шаблонах неэкранированный вывод ({!! !!}, dangerouslySetInnerHTML). Параметризованные запросы и стандартное экранирование — основная защита.

A04. Insecure Design — небезопасное проектирование

Код написан правильно, но сам процесс продуман неверно. В экспертизе нашего собственного продукта была именно такая находка: страница «оплата успешна» показывалась до подтверждения провайдера, а некоторые действия можно было выполнить без нужной проверки состояния.

Проверьте: работает ли каждый процесс со сменой состояния (оплата, подтверждение, отмена) на сервере как конечный автомат? Статус оплаты должен меняться только на основании подтверждающего запроса провайдера (callback/webhook).

A05. Security Misconfiguration — небезопасная конфигурация

Включён режим отладки, стандартные пароли, лишние открытые порты, нет заголовков, доверие к непроверенным заголовкам прокси. В нашем опыте к этой категории относилось несколько находок: открытые в интернет порты FTP и панели, доверие к X-Forwarded-Host (host header injection) и отправка в браузер полного списка маршрутов.

Проверьте: APP_DEBUG=false, открытые порты через nmap, заголовки безопасности, админ-панель только через IP allowlist.

A06. Vulnerable and Outdated Components — уязвимые и устаревшие компоненты

Библиотека, фреймворк или серверное ПО с известной уязвимостью.

Проверьте:

composer audit
npm audit --omit=dev

Кроме того, следите за версиями nginx, PHP и базы данных.

A07. Identification and Authentication Failures — ошибки аутентификации

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

Проверьте: есть ли rate limiting на входе и восстановлении пароля; обновляется ли ID сессии после входа; есть ли у cookie флаги Secure, HttpOnly, SameSite.

A08. Software and Data Integrity Failures — нарушения целостности

Получение кода или данных из непроверенного источника: скрипт с CDN без атрибута integrity, неподписанные обновления, десериализация недоверенных данных.

Проверьте: Subresource Integrity для внешних скриптов (integrity="sha384-..."); не применяется ли unserialize() к пользовательским данным; кто может вносить изменения в CI/CD.

A09. Security Logging and Monitoring Failures — недостаток логирования и мониторинга

Даже при атаке никто не узнаёт: неудачные входы, отклонённые запросы, действия администраторов не фиксируются.

Проверьте: пишутся ли важные события в лог; нет ли в логах паролей и токенов; смотрит ли кто-то логи или настроены ли оповещения.

A10. Server-Side Request Forgery (SSRF)

Сервер отправляет запрос на URL, указанный пользователем, и атакующий направляет его на внутренние сервисы (например, 127.0.0.1 или адрес метаданных облака).

Проверьте: есть ли функции вроде «загрузить картинку по URL» или адреса webhook; если есть, ограничены ли адреса allowlist'ом и заблокированы ли внутренние диапазоны IP.

OWASP Top 10 — не полный стандарт проверки, а документ для повышения осведомлённости. Для более глубокой проверки используются требования OWASP ASVS.

Как использовать список на практике

1. Свяжите каждый пункт с конкретными местами в проекте: какой контроллер, какая настройка, какой процесс.
2. Автоматические инструменты (аудит зависимостей, сканер заголовков, сканер портов) быстро закрывают A02, A05, A06.
3. A01, A04 и A07 требуют ручного просмотра — сканер не понимает бизнес-логику.
4. Фиксируйте каждую найденную проблему с идентификатором CWE: так проще сопоставлять находки с отчётом экспертизы.

Итог

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

Хотите быстро посмотреть свой проект по OWASP Top 10? Оставьте заявку на сканирование — Claude AI агент и наш специалист покажут состояние по основным категориям.