OWASP Top 10 для разработчиков

#Что такое OWASP Top 10

OWASP Top 10 — короткий список из десяти категорий риска, самых важных для веб-приложений. OWASP (Open Worldwide Application Security Project) — некоммерческая организация, которая публикует бесплатные материалы по безопасности. Текущее издание вышло в 2025 году и стало восьмым в серии.

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

Издание 2025 года опирается на два вида данных. Первый вид — результаты тестирования: тринадцать названных организаций и несколько анонимных участников прислали данные более чем по 2.8 миллиона приложений, и в них посчитано, сколько приложений содержали хотя бы один случай каждой слабости. Второй вид — данные об уязвимостях: около 220,000 записей CVE из американской National Vulnerability Database, сопоставленных с 643 CWE. Автоматические тесты видят не всё, поэтому две категории из десяти взяты из опроса сообщества.

Каждая категория объединяет родственные CWE из каталога Common Weakness Enumeration, который ведёт MITRE. По данным OWASP, список 2025 года охватывает 248 CWE.

#Зачем это разработчикам

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

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

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

Порядок взят из издания 2025 года. Он задаёт последовательность чтения и не говорит, что исправлять первым в вашем приложении. В каждом разделе есть простой пример, главная защита, CWE, которые OWASP относит к категории, и шпаргалка.

#A01:2025 Broken Access Control

Контроль доступа определяет, что разрешено аутентифицированному пользователю. Сюда входят проверки, которых нет, которые работают неверно или выполняются только в браузере. По данным OWASP, та или иная форма этого изъяна нашлась в каждом протестированном приложении.

Пример: страница заказа открывается по адресу /orders/1041. Если заменить номер на /orders/1042, откроется заказ другого клиента, потому что сервер не проверяет владельца.

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

CWE: CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization, CWE-918 Server-Side Request Forgery (SSRF), всего 40 сопоставленных записей.

Шпаргалка: Authorization Cheat Sheet.

#A02:2025 Security Misconfiguration

Система защищена ровно настолько, насколько защищена её конфигурация. Сюда входят оставленные учётные записи по умолчанию, включённые отладочные функции, подробные сообщения об ошибках, отсутствующие заголовки безопасности и облачные хранилища с неверными правами.

Пример: стейджинг-сервер работает с паролем админа по умолчанию из инструкции по установке и показывает полные стек-трейсы любому посетителю.

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

CWE: CWE-16 Configuration, CWE-260 Password in Configuration File, CWE-15 External Control of System or Configuration Setting, всего 16 сопоставленных записей.

Справка: глава V13 Configuration в ASVS. Шпаргалки для этой категории в OWASP нет.

#A03:2025 Software Supply Chain Failures

В вашем приложении работает код, написанный не вами. Эта категория описывает путь программы от исходников до продакшена: зависимости, инструменты сборки, реестры и каналы обновлений. В OWASP отмечают, что категория вышла за пределы компонентов с известными уязвимостями и заняла первое место в опросе сообщества.

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

Главная защита: знайте, что вы поставляете. Формируйте перечень компонентов (SBOM), отслеживайте транзитивные зависимости, удаляйте неиспользуемые пакеты и держите реестр компонентов актуальным.

CWE: CWE-1104 Use of Unmaintained Third Party Components, CWE-1395 Dependency on Vulnerable Third-Party Component и ещё четыре сопоставленные записи.

Шпаргалки: Vulnerable Dependency Management Cheat Sheet и Dependency Graph SBOM Cheat Sheet.

#A04:2025 Cryptographic Failures

Сюда относятся отсутствие криптографии, слабые алгоритмы, небрежная работа с ключами и пропущенные проверки сертификатов. Часто алгоритм вполне исправен, а ошибка в том, что решение вообще никто не принял: данные идут по обычному HTTP или лежат в хранилище, которое никто не проверял.

Пример: форма входа передаёт пароли по обычному HTTP или хранит их с быстрым хешем без соли.

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

CWE: CWE-261 Weak Encoding for Password, CWE-319 Cleartext Transmission of Sensitive Information, CWE-321 Use of Hard-coded Cryptographic Key, всего 32 сопоставленные записи.

Шпаргалки: Transport Layer Protection Cheat Sheet и Password Storage Cheat Sheet.

#A05:2025 Injection

Инъекция возникает, когда недоверенный ввод попадает в интерпретатор (движок SQL, оболочку операционной системы, браузер) и тот выполняет часть ввода как инструкции. Среди распространённых форм OWASP называет инъекции в SQL, NoSQL, команды ОС, ORM, LDAP и языки выражений. В издании 2025 года сюда же входит межсайтовый скриптинг (XSS).

Пример: обработчик поиска подставляет текст пользователя в строку SQL. Кавычка в этом тексте меняет смысл запроса.

Главная защита: используйте безопасный API, который разделяет данные и команды, например параметризованные запросы или ORM. Проверяйте ввод на сервере по списку разрешённых значений. Там, где без динамического вывода не обойтись, применяйте правила экранирования целевого интерпретатора. Имена таблиц и столбцов так не экранируются, поэтому вообще не берите их из пользовательского ввода.

CWE: CWE-20 Improper Input Validation, CWE-74 Injection, CWE-78 OS Command Injection, CWE-79 Cross-site Scripting, всего 37 сопоставленных записей.

Шпаргалки: Injection Prevention Cheat Sheet и SQL Injection Prevention Cheat Sheet.

#A06:2025 Insecure Design

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

Пример: эндпоинт скидок раз за разом принимает один и тот же купон, потому что повторное использование никто не рассматривал как угрозу.

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

CWE: CWE-269 Improper Privilege Management, CWE-256 Unprotected Storage of Credentials, CWE-73 External Control of File Name or Path, всего 39 сопоставленных записей.

Шпаргалка: Secure Product Design Cheat Sheet.

#A07:2025 Authentication Failures

Из-за этих сбоев внутрь попадает посторонний либо атакующий может пробовать, пока одна из попыток не сработает. Сюда входят credential stuffing, password spraying, слабое восстановление аккаунта, отсутствие многофакторной аутентификации (MFA) и сессии, которые остаются действительными после выхода.

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

Главная защита: требуйте MFA везде, где можете, блокируйте автоматические попытки, удаляйте учётные записи по умолчанию и проверяйте новые пароли по списку распространённых. OWASP предлагает брать 10,000 худших паролей.

CWE: CWE-287 Improper Authentication, CWE-259 Use of Hard-coded Password, CWE-290 Authentication Bypass by Spoofing, всего 36 сопоставленных записей.

Шпаргалка: Authentication Cheat Sheet.

#A08:2025 Software or Data Integrity Failures

Целостность означает, что код или данные соответствуют ожиданиям и не менялись по пути. Эта категория описывает автообновления без проверки подписи, скрипты с CDN без проверки целостности, пайплайны CI/CD, которые берут артефакты из непроверенных мест, и десериализацию недоверенных объектов.

Пример: страница загружает файл JavaScript со стороннего CDN без атрибута integrity. Если файл изменят, изменённый код выполнится у каждого посетителя.

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

CWE: CWE-345 Insufficient Verification of Data Authenticity, CWE-494 Download of Code Without Integrity Check, CWE-502 Deserialization of Untrusted Data, всего 14 сопоставленных записей.

Шпаргалка: Software Supply Chain Security Cheat Sheet.

#A09:2025 Security Logging and Alerting Failures

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

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

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

CWE: CWE-778 Insufficient Logging, CWE-532 Insertion of Sensitive Information into Log File, CWE-117 Improper Output Neutralization for Logs, всего 5 сопоставленных записей.

Шпаргалки: Logging Cheat Sheet и Application Logging Vocabulary Cheat Sheet.

#A10:2025 Mishandling of Exceptional Conditions

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

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

Главная защита: перехватывайте ошибки там, где они возникают, и обрабатывайте их осознанно. Добавьте глобальный обработчик исключений как страховку. Если многошаговая операция сорвалась на полпути, откатите её и завершите с отказом (fail closed).

CWE: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-252 Unchecked Return Value, CWE-248 Uncaught Exception, всего 24 сопоставленные записи.

Шпаргалка: Error Handling Cheat Sheet.

#Чем Top 10 не может служить

Полным стандартом он не считается. Десять категорий не опишут все требования к защищённому приложению, и многие риски лежат за пределами списка. Успешная проверка по Top 10 не делает приложение защищённым.

Закрыть его как чек-лист тоже нельзя. Категории описывают причины, поэтому одна функция может затрагивать несколько категорий, а одна категория охватывает множество разных багов. Команды, которые просто ставят галочки, часто исправляют примеры и оставляют шаблон, который их породил.

Требований в нём тоже нет. Для них в OWASP есть Application Security Verification Standard (ASVS), набор требований безопасности для проектирования, разработки и тестирования веб-приложений и сервисов. Текущая версия 5.0.0 опубликована 30 мая 2025 года. Top 10 подходит, чтобы объяснить риск и решить, куда смотреть в первую очередь. Когда нужны требования, по которым можно разрабатывать и проверять, берите ASVS.

#Как применить список к настоящей функции

1. Выберите одну функцию, например вход, оформление заказа или загрузку файлов.
2. Пройдите по десяти категориям и отметьте те, что к ней относятся.
3. Для каждой назовите меру контроля в вашей архитектуре и тест, который её подтверждает. Если вы используете ASVS, запишите идентификатор требования.
4. Занесите результат в модель угроз или бэклог, указав категорию и CWE вместе с названием бага. Повторяйте разбор после изменений в зависимостях и деплое, потому что A02, A03 и A08 меняются вместе с окружением.

#Практика: сопоставляем три категории Juice Shop

Вы запустите на своей машине OWASP Juice Shop, намеренно уязвимое веб-приложение, прочитаете его скорборд и сопоставите три категории заданий с пунктами Top 10. Ничего эксплуатировать не нужно. Читайте описания заданий, не заглядывая в решения, и держите приложение привязанным к localhost.

Понадобится Docker. Вывод ниже получен в Docker 29.8.2 на Windows 11 с Git Bash. Команды работают в любой оболочке POSIX.

#Шаг 1: проверьте Docker

docker --version
docker info --format '{{.ServerVersion}}'

Полученный вывод:

Docker version 29.8.2, build 7fc2dff
29.8.2

#Шаг 2: запустите Juice Shop только на loopback

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

Префикс 127.0.0.1: публикует порт только на интерфейсе loopback, поэтому другие машины до него не достанут. На машине, где я выполнял эти шаги, контейнер из того же образа уже работал под именем juice-local, так что второй я не запускал. Проверьте, что запущено:

docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'

Строка Juice Shop из полученного вывода:

juice-local bkimminich/juice-shop 127.0.0.1:3000->3000/tcp

#Шаг 3: убедитесь, что приложение отвечает

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
curl -s http://127.0.0.1:3000/rest/admin/application-version

Полученный вывод:

200
{"version":"20.3.0"}

Ваша версия может отличаться. Запишите её, потому что названия и категории заданий меняются от релиза к релизу.

#Шаг 4: посчитайте задания по категориям

curl -s http://127.0.0.1:3000/api/Challenges/ -o challenges.json
python -c "import json,collections; d=json.load(open('challenges.json'))['data']; print(len(d)); [print(v,k) for k,v in sorted(collections.Counter(x['category'] for x in d).items())]"

Полученный вывод:

116
12 Broken Access Control
4 Broken Anti Automation
9 Broken Authentication
5 Cryptographic Issues
12 Improper Input Validation
14 Injection
3 Insecure Deserialization
6 Miscellaneous
4 Observability Failures
5 Security Misconfiguration
3 Security through Obscurity
17 Sensitive Data Exposure
2 Unvalidated Redirects
9 Vulnerable Components
9 XSS
2 XXE

#Шаг 5: откройте скорборд

Откройте в браузере http://127.0.0.1:3000/#/score-board и сравните категории с числами выше. Если они расходятся, запишите свою версию Juice Shop.

#Шаг 6: сопоставьте три категории с Top 10

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

Почему подходит каждая строка:

• A01. Контроль, который решает, кто может попасть в административный раздел, отсутствует или работает неверно, а задание прямо называет этот раздел целью.
• A05. Категория посвящена недоверенному вводу, который попадает в интерпретатор. В описании интерпретатор не назван, поэтому укажите, что совпала категория, без привязки к конкретной технике.
• A02. Вывод и обработка ошибок зависят от настроек. То же поведение подходит и под A10, поскольку в издании 2025 года CWE-209 относится к A10. Укажите, какой пункт вы выбрали и почему.

Названия категорий в Juice Shop придуманы самим проектом. Например, его категория XSS в списке 2025 года соответствует A05. Сопоставляйте по первопричине и указывайте CWE.

#Шаг 7: остановите и удалите лабораторию

docker ps --format '{{.Names}} {{.Image}}'
docker stop <container-name>
docker rm <container-name>

Замените <container-name> именем из первой команды. Контейнер запущен с -d и без --rm, поэтому после остановки он останется на диске, пока вы его не удалите.

#Типичные ошибки

• Считать список полным. Многие риски не попадают ни в одну категорию. Когда нужны требования, берите ASVS.
• Сопоставлять по названию бага. Сопоставляйте по первопричине и указывайте CWE. Название вроде «XSS» приводит к CWE, а уже по CWE определяется категория.
• Исправлять пример и оставлять шаблон. Если эндпоинт удаления проверяет владельца, а эндпоинт обновления нет, A01 всё ещё открыт.
• Выставлять лабораторию наружу. Публикация Juice Shop на 0.0.0.0 или на облачном хосте выводит в интернет намеренно уязвимое приложение.
• Тестировать за пределами лаборатории. Сканирование и шаги атаки допустимы только на системах, которые принадлежат вам или которые вам разрешено тестировать.
• Писать секреты в логи при отладке. A09 включает логи, из которых утекают учётные данные, и при отладке такое случается легко.

#Что дальше

• Прочитайте главы ASVS, которые соответствуют вашим категориям. Для контроля доступа начните с ASVS V8 Authorization.
• Прочитайте шпаргалки, указанные в каждом разделе. Они короткие и написаны для тех, кто внедряет меры контроля.
• Откройте страницы CWE для слабостей, которые реально есть в вашем коде.
• Следующий шаг — статья SQL-инъекции на примере Juice Shop, где категория Injection разбирается подробнее в той же лаборатории.

#Источники

• OWASP Top 10:2025, https://owasp.org/Top10/ (redirects to https://top10.owasp.org/)
• OWASP Application Security Verification Standard, https://owasp.org/www-project-application-security-verification-standard/
• OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/
• MITRE Common Weakness Enumeration, https://cwe.mitre.org/
• OWASP Juice Shop project, https://owasp.org/www-project-juice-shop/
• Docker port publishing, https://docs.docker.com/engine/network/port-publishing/