Прямой ответ
OWASP Top 10 — не список для отчёта перед аудитом, а каталог классов ошибок, которые разработчик совершает сам: из десяти пунктов восемь закрываются привычками написания кода, а не «системой безопасности». Рабочее прочтение для практика: A01 Broken Access Control — «проверил ли я права на каждый объект» (самый частый класс в вебе); A02 криптографические провалы — «не изобретаю ли я шифрование»; A03 инъекции — параметризация и никакого eval (детальный разбор); A06 уязвимые компоненты — обновление зависимостей (аудит); A07 провалы аутентификации — проверенные библиотеки вместо самописных (JWT/OAuth). Практический смысл списка — чек-лист ревью: пройдясь по десяти пунктам на каждом PR, команда закрывает большинство реальных векторов атак без единого «специалиста по безопасности» в штате.
A01: Broken Access Control — самый массовый класс
Суть: пользователь делает то, что разрешено другим, — читает чужой заказ по подменённому id, вызывает админский эндпоинт, видит лишние поля в ответе. В коде это выглядит безобидно: order = db.get(Order, order_id) без проверки order.user_id == current_user.id — объект найден, отдан, инцидент. Лечение системное: авторизация на уровне объекта (не «страница доступна», а «этот объект — ваш») — в FastAPI это зависимость-владелец, поднимающая объект сразу с фильтром по владельцу (404 вместо 403 для чужого — не раскрываем существование); IDOR-проверка в тестах («пользователь B не получает ресурс A» — отдельный тест на каждый доступ); массовое присваивание (mass assignment) — pydantic-модели на вход с явным набором полей (никаких **request.json в конструктор ORM — «is_admin: true» в теле запроса не должно становиться колонкой); вертикальный доступ — middleware/зависимость ролей на роутерах, а не «внутри обработчика проверим».
A02 и A03: криптография и инъекции
A02 (Cryptographic Failures) в прикладном коде — это почти всегда не «сломанный AES», а прикладные провалы: пароли без bcrypt/argon2 (или с md5 «для скорости»), TLS отключённый «временно» (verify=False в requests на проде — отключает проверку сертификата целиком), чувствительные данные в логах/URL-параметрах (токен в query-строке оседает в access-логах прокси), секреты в git. Правило: криптография — только стандартными библиотеками и проверенными сервисами (хеш пароля — passlib/argon2-cffi, TLS — библиотеки с дефолтами, «своя схема» — красный флаг на ревью). A03 (Injection) — SQL/shell/eval/LDAP/NoSQL: данные пользователя, попавшие в интерпретируемый контекст; полный разбор с примерами — в статье про инъекции; здесь главное — место в системе приоритетов: класс известен сорок лет, параметризация тривиальна, а находится в каждом третьем легаси-проекте.
A04–A07: дизайн, конфигурация, компоненты, аутентификация
A04 (Insecure Design) — новый акцент списка: уязвимость, заложенная в дизайне (бизнес-логика без лимитов — «купи товар за бонусы, которых нет»; восстановление пароля по предсказуемым вопросам; отсутствие rate limit на подбор кода) — лечится threat-modeling'ом до кода («как это сломать?» на этапе дизайна) и лимитами на критичные операции. A05 (Security Misconfiguration) — дефолты и конфиги: DEBUG=True на проде (отдаёт настройки и переменные окружения), открытые админки без авторизации, лишние открытые порты и эндпоинты (health/метрики наружу), verbose-ошибки пользователям; профилактика — чек-лист деплоя (Django deploy-checklist как пример) и сканирование конфигурации. A06 (Vulnerable Components) — зависимости с CVE: обновление и аудит (отдельная статья); здесь позиция: устаревшая зависимость — это дыра с открытым эксплойтом, обновление — часть разработки, а не «когда прижмёт». A07 (Identification and Authentication Failures) — сессии и логины: перебор паролей без блокировок/лимита, слабые требования, предсказуемые токены сессий, «remember me» без ротации; лечение — проверенные реализации (фреймворковые сессии, стандартные потоки OAuth), лимиты попыток, MFA для критичных доступов.
A08–A10: целостность, логи, SSRF
A08 (Software and Data Integrity Failures) — недоверенные источники кода и данных: pip-установка пакетов с тайпсквоттинговыми именами (typosquatting — reqeusts), CI/CD-пайплайны без фиксации версий действий, десериализация недоверенных данных (pickle — разбор), автообновления без проверок; лечение — lock-файлы с хешами, пины действий в CI по SHA, подпись артефактов там, где критично. A09 (Security Logging and Monitoring Failures) — не «логов мало», а «атаку не заметили»: провалы логина не логируются/не алертят, массовые 404 на подборе id не видны, логи без request_id не связываются; лечение — структурированные логи событий безопасности (формат), алерты на аномалии (мониторинг). A10 (SSRF) — сервер ходит по URL из ввода: «проверить доступность сайта» становится сканером внутренней сети (метаданные облака 169.254.169.254 с credentials — канонический инцидент); лечение — белый список схем/хостов, запрет приватных диапазонов в резолвинге, отдельные egress-правила для фичи.
Практика: чек-лист ревью и ASVS
Встроить список в процесс дешевле, чем кажется: PR-чек-лист из десяти вопросов (по пункту на класс: «есть ли в диффе доступ к объектам без проверки владельца? новый ввод в SQL/shell? новые зависимости? изменение аутентификации?») — ревьюер проходит за минуту; bandit + pip-audit в CI ловят автоматизируемое (инструменты); для системной работы — OWASP ASVS (Application Security Verification Standard): три уровня требований к приложению, применяется не «весь сразу», а как целевой профиль (внутренний инструмент — уровень 1, публичный сервис с данными — уровень 2, платежи/здоровье — 3). Отдельная привычка — threat-modeling lite на фичу: перед реализацией «как это сломать / что злоупотребить» тремя предложениями в описании задачи; половина A04-проблем умирает на этом этапе почти бесплатно.
FAQ
Top 10 — это рейтинг частоты? Это «наиболее критичные риски» по сочетанию распространённости и влияния, пересматриваемые раз в несколько лет (список 2021 — актуальный каркас); не «статистика атак» и не полный каталог — за его пределами остаются бизнес-логика специфичных доменов и атаки на клиентов.
Нужен ли пентест, если команда следует Top 10? Следование списку закрывает типовое; пентест/bug bounty находят специфичное (комбинации, бизнес-логика, конфигурация периметра). Порядок разумный: сначала гигиена по списку (дешево, закрывает 80%), потом внешний взгляд на критичный контур.
Как обучить команду без курсов «по безопасности»? Разбор собственного кода: bandit по репозиторию с обсуждением находок, ретроспектива по каждому найденному багу безопасности («почему пропустили на ревью?»), и этот чек-лист в шаблоне PR. Реальные находки в своём коде обучают быстрее любых слайдов.
Применим ли список к API без браузера? Да почти целиком: инъекции, доступы, зависимости, логирование, SSRF — серверные классы, не зависящие от клиента; браузероспецифичны XSS/CSRF-детали (для чистого API с токенами CSRF неактуален, XSS переезжает на фронтенд — но «отражение пользовательского ввода» остаётся риском в отчётах/письмах).
Источники: OWASP Top Ten, OWASP Cheat Sheet Series, ASVS — ссылки в шапке.