OWASP Top 10 2025 — это обзор десяти наиболее значимых категорий рисков безопасности веб-приложений. Его готовит международное сообщество OWASP, которое разрабатывает открытые рекомендации, методики и инструменты для защиты программного обеспечения. Число 2025 в названии обозначает год редакции документа.
Как устроен OWASP Топ-10
Каждая категория объединяет родственные ошибки в коде, проектировании, настройках приложения или процессах его разработки и эксплуатации. Например, к Injection относятся SQL-инъекции и межсайтовый скриптинг — XSS. Авторы по возможности группируют слабые места по причинам их возникновения, хотя некоторые категории описывают последствия, а сами категории могут пересекаться. Это помогает разработчикам понять, какие решения создают риск и что нужно изменить для защиты приложения.
Список периодически пересматривают с учетом результатов тестирования приложений и опроса специалистов по безопасности. Авторы оценивают распространенность слабых мест, возможность их эксплуатации и потенциальные последствия. Мнение сообщества помогает учесть проблемы, которые трудно обнаруживать при массовых проверках и которые поэтому могут быть слабо представлены в собранных данных.
OWASP Top 10 помогает разработчикам, тестировщикам и специалистам по безопасности разобраться в основных рисках и понять, какие ошибки создают уязвимости веб-приложений. На основе списка команда может составить план проверок для своего продукта. Конкретные требования и тесты подбирают с учетом того, как устроено приложение, какие данные оно обрабатывает и что в нем могут делать пользователи.
При составлении редакции 2025 года авторы учитывали результаты тестирования приложений и опрос сообщества. Восемь категорий выбрали на основе данных, еще две включили с учетом мнения специалистов. Такой подход позволяет учитывать риски, которые пока трудно выявлять массовыми автоматизированными проверками.
Место категории в списке не определяет срочность исправления конкретной ошибки. Для этого команда оценивает доступность уязвимой функции, характер данных и возможный ущерб. Например, подтвержденная SQL-инъекция в общедоступном сервисе может требовать немедленного исправления, хотя категория Injection занимает пятую строчку. Такой порядок работы соответствует рискориентированному подходу OWASP к AppSec.
Что изменилось в OWASP Top 10 по сравнению с 2021 годом
В описании релиза OWASP выделяет две новые категории и одно объединение. Новыми названы Software Supply Chain Failures и Mishandling of Exceptional Conditions. Категория цепочки поставки развивает прежнюю Vulnerable and Outdated Components. При объединении SSRF вошла в Broken Access Control.
В таблице сохранены официальные английские названия. Номера и прежние названия сверены с редакцией 2021 года.
Для разработчика особенно важны изменения в границах категорий. В A03 теперь важно учитывать, кто может повлиять на сборку и выпуск приложения. В A09 следует проверять доставку и обработку оповещений. Новая A10 требует заранее определить поведение системы при тайм-аутах, недоступности зависимостей и других сбоях.
Категории OWASP Top 10 2025: примеры и проверки
Рассмотрим, какие ошибки входят в каждую категорию, чем они опасны и как защитить приложение. Все примеры условные, а проверки рассчитаны на тестовую среду с учебными аккаунтами, искусственными данными и заглушками внешних сервисов.
A01. Broken Access Control — нарушения контроля доступа
Пользователь открывает счет через запрос GET /api/invoices/42. Сервер проверяет, что пользователь вошел в аккаунт, и выдает документ по его идентификатору. Принадлежность счета не проверяется, поэтому достаточно подставить идентификатор другого документа, чтобы получить чужие данные.
Как проверить. Создайте два тестовых аккаунта и по одному счету для каждого. Из первого аккаунта попробуйте открыть, изменить, удалить и скачать счет второго. Во всех этих случаях приложение должно отклонить запрос, сохранив чужие данные недоступными и неизменными.
Как защитить. Проверяйте на сервере, имеет ли пользователь право выполнять запрошенное действие с выбранным объектом. Учитывайте владельца документа, его организацию и другие ограничения приложения. Доступ к закрытым ресурсам следует запрещать по умолчанию и разрешать только после проверки прав.
A02. Security Misconfiguration — небезопасные настройки
В рабочей версии приложения оставили включенным отладочный режим. При ошибке сервис показывает трассировку стека, внутренние пути к файлам и сведения об используемых компонентах. Эти подробности помогают злоумышленнику изучить устройство приложения и найти дополнительные слабые места.
Как проверить. Запустите на тестовом стенде приложение с настройками, подготовленными для релиза, и вызовите заранее предусмотренную ошибку. Посмотрите, какие сведения сервер вернет в ответ. Дополнительно проверьте доступность диагностических страниц, служебных интерфейсов и ненужных функций.
Как защитить. Отключите отладочный режим и неиспользуемые компоненты. Контролируйте изменения настроек безопасности и проверяйте их при развертывании приложения. Пользователь должен получать понятное сообщение об ошибке без технических подробностей. Доступ к диагностической информации следует оставить только уполномоченным сотрудникам.
A03. Software Supply Chain Failures — нарушения безопасности цепочки поставки ПО
Во время сборки система скачивает вспомогательный скрипт из внешнего репозитория и запускает его с правами публикации релиза. Версия скрипта не зафиксирована, а изменения источника никто не согласует. Если злоумышленник получит контроль над репозиторием, он сможет подменить скрипт и повлиять на выпускаемое приложение.
Как проверить. Выясните, откуда система сборки получает код, библиотеки, образы и инструменты. Проверьте, кто может менять эти источники и настройки самой сборки. Отдельно изучите ее права на публикацию и доступ к секретам, например ключам и токенам.
Как защитить. Используйте доверенные источники и фиксируйте версии компонентов. Ограничьте права сборочных процессов, защитите репозитории и настройте согласование изменений. Ведите SBOM — перечень компонентов приложения, включая зависимости, которые подключаются через другие библиотеки. По этому перечню отслеживайте известные уязвимости и своевременно обновляйте компоненты.
A04. Cryptographic Failures — ошибки криптографической защиты
В базе пароли хранятся в виде MD5-хешей без уникального дополнительного значения для каждой записи. При утечке такой базы злоумышленник сможет быстро перебирать варианты паролей и сравнивать результаты с украденными хешами. Подбор упрощает и то, что одинаковые пароли дают одинаковые хеши.
Как проверить. Изучите код, который отвечает за сохранение и проверку паролей. Выясните, какой алгоритм используется, как он настроен и создается ли уникальная соль для каждой записи. Проводите проверку на искусственных учетных данных.
Как защитить. Используйте специализированный алгоритм хранения паролей, например Argon2id, через поддерживаемую библиотеку. Настройте параметры вычислительной сложности и убедитесь, что для каждой записи создается уникальная соль. Отдельно проверьте, как приложение шифрует остальные данные при передаче и хранении, управляет ключами и проверяет сертификаты.
A05. Injection — инъекции
Пользователь вводит фамилию в форму поиска, и приложение напрямую добавляет ее в строку SQL-запроса. Из-за этого введенные данные могут повлиять на структуру команды. Специально составленный ввод способен изменить смысл запроса и открыть доступ к закрытым записям.
Как проверить. Проследите, как значение из формы попадает в запрос к базе данных. Оно должно передаваться отдельным параметром. Например, фамилия с апострофом O’Neil должна обрабатываться как обычный текст. Для полноценной проверки защиты изучите код и выполните специализированные тесты.
Как защитить. Используйте параметризованные запросы, в которых текст команды и пользовательские значения передаются раздельно. Проверяйте участки с SQL, написанным вручную, в том числе в приложениях с ORM.
К этой категории также относится межсайтовый скриптинг — XSS. Для защиты от него нужны безопасные шаблоны, контекстное экранирование и очистка HTML, если приложение разрешает его ввод. Способ обработки зависит от того, куда попадают данные: в текст страницы, HTML-атрибут, адрес ссылки или другой контекст.
A06. Insecure Design — небезопасное проектирование
При проектировании возвратов в интернет-магазине предусмотрели проверку заказа перед возвратом денег. Но учет уже возвращенных денег в требования не включили, поэтому система рассматривает каждый запрос отдельно. В результате несколько частичных возвратов могут в сумме превысить стоимость покупки.
Как проверить. На тестовом заказе с заглушкой платежного сервиса попробуйте провести два последовательных частичных возврата, общая сумма которых превышает оплаченную. Система должна отклонить возврат, который нарушает это ограничение. Затем проверьте, соблюдаются ли остальные правила при изменении состояния заказа.
Как защитить. До начала разработки определите обязательные ограничения бизнес-процесса. В этом примере общая сумма возвратов должна оставаться в пределах оплаченной суммы. Закрепите правило в серверной логике и тестах, учитывая одновременные запросы. Найти подобные пробелы помогает моделирование угроз и разбор того, как пользователь может злоупотребить доступными функциями.
A07. Authentication Failures — ошибки аутентификации
Категория охватывает уязвимости механизмов входа, восстановления доступа и управления сессиями. Например, сервис позволяет несколько раз использовать одну ссылку для сброса пароля. Если старая ссылка попадет к постороннему, он сможет снова изменить пароль владельца аккаунта.
Как проверить. Запросите восстановление доступа для тестового аккаунта, смените пароль и повторно откройте ту же ссылку. Затем проверьте ссылку с истекшим сроком действия. В обоих случаях приложение должно отклонить запрос без изменений в аккаунте.
Как защитить. Используйте одноразовые токены восстановления с ограниченным сроком действия. Создавайте их криптографически стойким генератором и ограничивайте число запросов на восстановление доступа. Для входа применяйте многофакторную аутентификацию там, где это возможно. Также проверяйте, что завершенные сессии больше не дают доступа к аккаунту.
A08. Software or Data Integrity Failures — нарушения целостности ПО или данных
Приложение автоматически устанавливает обновления без проверки их подлинности и целостности. Если пакет подменят, система примет его за выпуск разработчика. В результате посторонний код сможет изменить работу приложения.
Как проверить. Возьмите учебный подписанный пакет и измените в нем безвредный текстовый файл. Затем запустите проверку пакета отдельно от установки. Измененный пакет должен быть отклонен до выполнения кода.
Как защитить. Проверяйте подпись обновления с помощью ключа, которому приложение заранее доверяет. Если проверка не пройдена, установка должна блокироваться. Аналогичные проверки нужны для критически важных данных, которые приложение получает извне и использует как доверенные.
A03 охватывает безопасность процесса поставки ПО. A08 посвящена проверкам целостности конкретного кода и данных. Одна уязвимость может затрагивать обе категории.
A09. Security Logging & Alerting Failures — ошибки журналирования и оповещения
Приложение записывает неудачные попытки входа в журнал. Оповещение о подозрительной серии попыток не настроено, поэтому ответственный сотрудник может узнать о проблеме слишком поздно.
Как проверить. В тестовой среде воспроизведите заранее согласованную последовательность событий, которая должна вызвать оповещение. Убедитесь, что события попали в журнал, правило сработало и уведомление дошло до получателя. Получатель должен понимать, что произошло и какие действия от него требуются.
Как защитить. Определите, какие события требуют оповещения. Согласуйте, кто получает уведомления, как эти сотрудники действуют при инциденте и кого подключают к решению проблемы. Защитите журналы от изменения и утраты, исключите запись паролей и токенов. Следите за количеством ложных срабатываний, чтобы важные уведомления не терялись среди остальных.
A10. Mishandling of Exceptional Conditions — некорректная обработка нештатных ситуаций
Перед выполнением операции приложение обращается к отдельному сервису проверки прав. Если ответ не приходит вовремя, обработчик ошибки разрешает действие, чтобы функция продолжала работать. Такое поведение называют fail-open: сбой ослабляет защиту и позволяет выполнить операцию без подтверждения прав.
Как проверить. Настройте заглушку сервиса проверки прав так, чтобы она имитировала тайм-аут, и повторите запрос. Приложение должно отказать в выполнении операции и сохранить данные неизменными. Дополнительно проверьте его поведение при отсутствии обязательных параметров и ошибках на промежуточных этапах обработки.
Как защитить. Заранее определите, как приложение должно безопасно завершать операцию при каждом возможном сбое. Если подтвердить право на действие невозможно, его следует отклонить. При ошибке система должна освобождать занятые ресурсы, корректно откатывать незавершенные транзакции и фиксировать сбой в журнале. Ограничения времени выполнения, числа запросов и потребления ресурсов помогают предотвратить часть таких ситуаций.
Почему нарушения контроля доступа остаются приоритетом
В данных, предоставленных для OWASP Top 10:2025, категория Broken Access Control лидирует по общему числу выявленных случаев слабых мест (Total Occurrences). Нарушения контроля доступа позволяют пользователям читать, изменять и удалять чужие данные или выполнять действия за пределами своих полномочий. Защита требует учета правил конкретного приложения. Например, сотрудники с одинаковой ролью могут иметь доступ к разным проектам. Поэтому сервер должен проверять, разрешено ли пользователю запрошенное действие с конкретным документом или записью.
Лучше начать проверку с таблицы прав доступа: укажите, какие данные и операции доступны каждой группе пользователей. Затем создайте на тестовом стенде аккаунты с разными ролями и из разных организаций. Через API попробуйте открыть чужие документы, изменить недоступные записи и вызвать административные функции из обычного аккаунта. Сервер должен отклонить запрещенные запросы, сохранив закрытые данные недоступными и неизменными. Включите эти сценарии в автоматические тесты и запускайте их при изменениях приложения.
Как превратить OWASP Top 10 в рабочий чек-лист
Сопоставьте категории OWASP Top 10 с функциями приложения и сформулируйте конкретные проверки. Для каждого пункта укажите ожидаемый результат и ответственного. Например, при проверке экспорта счетов пользователь одной организации запрашивает документы другой. Приложение должно отклонить запрос и не выдать чужие данные. Результат теста подтвердит, что ограничение работает.
Распределите проверки между тремя этапами. Один и тот же механизм защиты может потребовать внимания на каждом из них.
Для каждого пункта фиксируйте статус «пройдено», «не пройдено» или «не применимо» с пояснением. Сохраняйте дату, номер сборки и результат проверки. Заранее договоритесь, какие нерешенные проблемы блокируют выпуск и кто принимает решение по остальным рискам.
Главное об OWASP Top 10:2025
- OWASP Top 10 объединяет десять наиболее значимых категорий рисков безопасности веб-приложений. Список помогает разработчикам и тестировщикам разобраться в основах безопасности веб-приложений и составить план проверок. Конкретные требования подбирают с учетом устройства приложения, его функций и данных.
- В редакции 2025 года обновили состав категорий и их порядок. Ошибки настройки поднялись на второе место, категория уязвимых компонентов расширилась до безопасности всей цепочки поставки ПО. Обработку нештатных ситуаций выделили в отдельную категорию, SSRF включили в нарушения контроля доступа. В категории журналирования усилили внимание к оповещениям об угрозах.
- Уязвимости веб-приложений требуют разных мер защиты в зависимости от причины ошибки. Для защиты от SQL-инъекций используют параметризованные запросы, для безопасного восстановления доступа — одноразовые ссылки с ограниченным сроком действия. Проверки должны подтверждать, что эти механизмы работают и блокируют недопустимые действия.
- Broken Access Control остается приоритетом из-за распространенности ошибок и риска доступа к чужим данным. Сервер должен проверять права пользователя на каждое действие с конкретным документом или записью. Для проверки составляют таблицу прав и через API выполняют запрещенные запросы из аккаунтов с разными ролями и из разных организаций.
- Проверки по OWASP Top 10 включают в ревью кода, тестирование и подготовку к релизу. На ревью изучают реализацию защиты, при тестировании проверяют запрещенные действия и поведение приложения при сбоях. Перед выпуском проверяют сборку, настройки, зависимости и доставку оповещений. Для каждого пункта чек-листа указывают ответственного, ожидаемый результат и итог проверки.
