Как защитить веб-приложение: чек-лист по OWASP Top 10

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

Что такое OWASP Top 10 и как пользоваться чек-листом

OWASP — открытое международное сообщество, которое занимается безопасностью веб-приложений. Его самый известный документ, Top 10, — список наиболее распространённых и опасных категорий уязвимостей, который пересматривается раз в несколько лет. Важно понимать его статус: это документ для повышения осведомлённости, а не стандарт и не полный список требований. Прохождение «десятки» не означает, что приложение безопасно, — оно означает, что вы закрыли самые массовые проблемы. Для детальной проверки у того же сообщества есть ASVS — стандарт проверки безопасности приложений с уровнями требований. Ниже мы опираемся на категории редакции 2021 года — она хорошо знакома разработчикам; в редакции 2025 года порядок и формулировки частично изменились, в частности отдельный акцент сделан на цепочке поставок ПО, но суть проверок от этого не меняется.

Как пользоваться чек-листом:

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

Доступ и защита данных

A01. Нарушение контроля доступа. Это самая частая категория, и она почти никогда не ловится автоматическими сканерами, потому что сканер не знает, что пользователю А нельзя видеть данные пользователя Б. Классический пример — прямые ссылки на объекты: кабинет показывает заказ по адресу /orders/1043, а при замене на 1044 открывается чужой заказ. Та же история с API: интерфейс скрывает кнопку «удалить», но запрос на удаление сервер выполняет у любого авторизованного пользователя.

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

Как выстроить ролевую модель, чтобы проверять было что, мы разбирали в статье про права доступа.

A02. Ошибки криптографии и раскрытие данных. Что проверить:

• HTTPS на всех страницах и API, редирект с HTTP, заголовок HSTS. Подробности настройки — в статье про SSL-сертификат.
• Пароли — только хеш медленным алгоритмом (argon2id, bcrypt) с солью.
• Чувствительные поля — паспортные данные, реквизиты, токены внешних сервисов — шифруются в базе, ключи хранятся отдельно от данных.
• Персональные данные не пишутся в логи и не отправляются в сторонние системы аналитики.
• Вы не храните то, что вам не нужно. Самые защищённые данные — те, которых у вас нет.

Инъекции и небезопасный дизайн

A03. Инъекции. Инъекция — это ситуация, когда пользовательский ввод попадает в запрос к базе, командную строку или шаблон и начинает исполняться как код. SQL-инъекции стали реже благодаря ORM, но возвращаются там, где разработчик написал «сырой» запрос со склейкой строк ради одного сложного отчёта. В эту же категорию в редакции 2021 года вошёл XSS — внедрение скрипта в страницу, которую увидят другие пользователи.

• Все запросы к базе — параметризованные. Отдельно найдите в коде все места, где запрос собирается строкой.
• Для NoSQL-баз — проверка типов входящих данных: объект вместо строки в поле логина — классический обход проверки.
• Вывод в HTML экранируется; вставка «сырого» HTML от пользователя — только через проверенный санитайзер.
• Заголовок Content Security Policy ограничивает, откуда могут загружаться и исполняться скрипты.
• Вызовы командной оболочки с пользовательским вводом — по возможности не использовать вовсе.

A04. Небезопасный дизайн. Эту категорию не исправить кодом, если ошибка заложена в логике. Можно ли заказать товар в количестве −1 и получить возврат? Можно ли применить один промокод десять раз, отправив десять запросов одновременно? Можно ли пройти оплату, подменив сумму в запросе? Списываются ли бонусы до или после проверки остатка? Такие вопросы задаются на этапе проектирования: для каждого процесса, где есть деньги, лимиты или права, команда спрашивает «а как этим можно злоупотребить». Ответы превращаются в требования и тесты.

Конфигурация и компоненты

A05. Ошибки конфигурации. Что проверить:

• Режим отладки выключен на продакшене; страницы ошибок не показывают стек вызовов и версии компонентов.
• Нет учётных записей по умолчанию и тестовых пользователей с простыми паролями.
• Служебные каталоги и файлы недоступны снаружи: .git, .env, резервные копии, дампы базы.
• CORS не разрешает запросы с любого домена для API с авторизацией.
• Выставлены заголовки безопасности: CSP, X-Content-Type-Options, Referrer-Policy, запрет встраивания во фреймы.
• Хранилища файлов не открыты на публичное чтение «временно».
• Панели баз данных и администрирования не торчат в интернет без ограничения по адресам.

A06. Уязвимые и устаревшие компоненты. Большая часть кода современного веб-приложения написана не вашей командой: фреймворк, библиотеки, их зависимости. Уязвимость в любой из них — ваша уязвимость. Минимальный режим: зависимости зафиксированы в lock-файле, проверка на известные уязвимости запускается автоматически при каждой сборке (npm audit и аналоги), обновления безопасности ставятся по регламенту, а не «когда будет время». Отдельно стоит удалять неиспользуемые пакеты: каждый лишний — это лишняя поверхность атаки. К этой же теме относится и выбор пакетов: малоизвестная библиотека с одним автором и без обновлений — риск, даже если сегодня в ней нет известных дыр.

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

A07. Ошибки аутентификации. Сюда относится всё, что связано со входом: перебор паролей без ограничений, слабое восстановление доступа, сессии, которые не завершаются после смены пароля, отсутствие второго фактора у администраторов. Подробно о том, какую политику утвердить для пользовательских аккаунтов, — в статье про 2FA и пароли. Для чек-листа минимум такой: ограничение частоты попыток входа, одинаковые сообщения об ошибке, короткоживущие одноразовые токены сброса, обязательный второй фактор для админ-панели, флаги Secure, HttpOnly и SameSite у сессионных кук.

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

• Сборка и выкладка идут через контролируемый конвейер, а не с ноутбука разработчика; доступ к нему защищён вторым фактором.
• Сторонние скрипты с CDN подключаются с проверкой целостности (атрибут integrity) или размещаются у себя.
• Приложение не десериализует произвольные данные от пользователя в объекты.
• Вебхуки от платёжных систем и интеграций проверяются по подписи, а не принимаются на веру.

Мониторинг, SSRF и то, что за пределами десятки

A09. Недостаточное логирование и мониторинг. Без журналов вы не узнаете об атаке, пока о ней не напишут клиенты, и не сможете понять, что именно произошло. Логировать нужно входы и неудачные попытки входа, смену прав, паролей и контактных данных, массовые выгрузки, ошибки доступа. Журналы хранятся отдельно от приложения, так, чтобы взломщик не мог их подчистить. И главное — на аномалии кто-то реагирует: всплеск неудачных входов или сотни ошибок доступа за минуту должны превращаться в уведомление ответственному, а не в строчки, которые никто не читает.

A10. Подделка запросов со стороны сервера (SSRF). Если приложение умеет само ходить по адресу, который указал пользователь, — загрузить картинку по ссылке, проверить вебхук, сделать превью страницы, — злоумышленник может указать адрес внутренней сети или служебный адрес облачной инфраструктуры и получить то, что снаружи недоступно. Защита: список разрешённых доменов там, где это возможно, запрет обращений к внутренним и служебным диапазонам адресов, отдельный изолированный сервис для таких загрузок и отказ от следования редиректам без проверки.

За пределами десятки, но проверить обязательно:

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

Как проверять и кто за это отвечает

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

Условный пример: проверка клиентского кабинета перед релизом

Возьмём условный кабинет B2B-клиента: заказы, счета, сотрудники клиента с ролями «администратор» и «менеджер», загрузка договоров в PDF. Команда выделяет на проверку по чек-листу один рабочий день и распределяет его так.

• Первые два часа — контроль доступа. Заводятся два клиента и по два пользователя в каждом. Проверяется, что менеджер не видит счета, если ему не положено, а пользователь одного клиента не открывает заказы и договоры другого ни через интерфейс, ни прямым запросом к API.
• Час — загрузка файлов: попытка загрузить исполняемый файл с расширением .pdf, файл огромного размера, файл с именем, содержащим путь к каталогу.
• Час — вход и восстановление: перебор, токены сброса, завершение сессий после смены пароля, второй фактор у администратора клиента.
• Час — конфигурация: заголовки, страницы ошибок, доступность служебных файлов, режим отладки.
• Остаток дня — бизнес-логика: одновременные запросы на одно и то же действие, отрицательные суммы, повторное использование ссылок и одноразовых кодов, плюс прогон сканера зависимостей и автоматического сканера по тестовому стенду.

Результат — список находок с приоритетами: что блокирует релиз, что исправляется в ближайшем спринте, какой риск принят осознанно и кем. Именно такой список, а не ощущение «вроде всё нормально», и есть результат работы с чек-листом.

Чек-лист не работает, если он «общий». У каждого проекта должен быть человек, который отвечает за безопасность релиза: проводит проверку или организует её, ведёт список находок и имеет право остановить выкладку. В небольшой команде это ведущий разработчик, у подрядчика — технический руководитель проекта. Владельцу бизнеса достаточно задать два вопроса перед запуском: «кто проверял по OWASP» и «где список того, что нашли и что приняли как риск». Если ответов нет, значит, проверки не было.

Частые ошибки при работе с чек-листом

• Проверить один раз и считать вопрос закрытым навсегда. Каждый новый раздел приложения приносит новые точки доступа.
• Положиться на сканер и не проверять права вручную.
• Закрыть пункт формально: «CSP включён» — но с разрешением на любой встроенный скрипт.
• Проверять только интерфейс и забыть про API, мобильное приложение и интеграции.
• Откладывать обновление зависимостей до «большого рефакторинга», который никогда не наступает.

Вывод

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