Современные API — это основа цифровых сервисов, но их рост и усложнение приводят к увеличению числа уязвимостей, которые часто выявляются слишком поздно — уже после инцидентов. Типичные проблемы:

• Ручная проверка безопасности — медленная, дорогая и подвержена человеческому фактору.
Отсутствие автоматизированного анализа соответствия API его контракту (OpenAPI/Swagger).

• Недостаточная защита от OWASP API Top 10 угроз, таких как BOLA (Broken Object Level Authorization), инъекции, слабая аутентификация и т.д.

• Нет единого инструмента, который бы объединял статический анализ, динамическое тестирование и валидацию контракта в одном решении.

Цель кейса — разработать автоматизированный инструмент анализа безопасности и корректности API, который:

• Работает в один клик или в автоматическом режиме (например, как часть CI/CD).
• Анализирует реальные или спецификационные (OpenAPI) описания API.
• Выявляет уязвимости из OWASP API Top 10.
• Проверяет соответствие поведения API его контракту (валидация схемы, типов, обязательных полей и т.д.).
• Предоставляет понятный отчет с рекомендациями по устранению проблем.
• Может быть интегрирован в DevOps-процессы.

• Анализ уязвимостей:
Поддержка проверки на BOLA, IDOR, инъекции, слабую аутентификацию, избыточные данные в ответах и другие OWASP API Top 10 угрозы.
Возможность указания целевого API по URL или загрузки спецификации (OpenAPI/Swagger).

• Валидация контракта:
Сравнение фактического поведения API с его спецификацией.
Обнаружение расхождений: отсутствующие поля, неожиданные типы данных, неописанные эндпоинты.

• Автоматизация:
Поддержка запуска через CLI или API.
Возможность интеграции в CI/CD (например, GitHub Actions, GitLab CI).

• Отчетность:
Генерация отчета в формате HTML/PDF/JSON.
Уровни критичности уязвимостей (High/Medium/Low).
Рекомендации по исправлению.

• Интуитивный интерфейс (если есть UI) или понятная документация (если CLI/API-only).
• Высокая скорость анализа — не более 5 минут на средний API (20-30 эндпоинтов).
• Минимальные зависимости — решение должно быть легко развертываемым.
• Поддержка популярных форматов спецификаций: OpenAPI 3.1+, Swagger 2.0.

• Поддержка асинхронных форматов asyncapi 2.6+
• Поддержка фаззинга (генерация нестандартных запросов для выявления нестабильности).
• Возможность обнаружения «открытых дверей» — например, эндпоинтов без аутентификации, debug-интерфейсов, тестовых данных.
• Модульность архитектуры — возможность подключать новые проверки как плагины.

• Обязательно использование Java 17+

В первую очередь, нам интересно будет рассмотреть решения участников, реализованные через взаимодействие с ГОСТ-шлюзом. Информацию об этом вы можете получить здесь.

Для решения задачи участникам рекомендуется использовать следующие ресурсы:

OWASP API Security Top 10:
ㅤhttps://owasp.org/www-project-api-security/

Open API Specification:
ㅤhttps://swagger.io/specification/

API для тестирования:

• Процесс подключения к стендам Open API
• Sandbox-платформа OpenAPI (пароль 321)

Инструменты для анализа API (для вдохновения):
ㅤZAP (Zed Attack Proxy)
ㅤPostman + Newman для валидации
ㅤSpectral (для линтинга OpenAPI)
ㅤKiterunner (для обнаружения скрытых эндпоинтов)

Загрузите решение на платформу хакатона не позднее 9 ноября 22:00 МСК в следующем виде:

1. Ссылка на выгруженный проект из VCS в формате .zip*
2. Ссылка на открытый репозиторий VCS*
3. Ссылка видео-демо работы проекта (видео, показывающее процесс работы вашего решения, с комментариями или без них, не длиннее 2 минут) (при наличии).
4. Ссылка на презентацию проекта (формат .pdf).*

В качестве облачного сервиса используйте Яндекс Диск
*обязательно для загрузки 

Первый этап

Бизнес критерии
• Практическая применимость решения 
• Потенциал для стандартизации или коммерциализации 
• Глубина и релевантность выявляемых уязвимостей с точки зрения реальных угроз 

Технические критерии
• Покрытие известных классов уязвимостей API (OWASP и другие признанные источники) 
• Точность и полнота валидации соответствия поведения API его спецификации 
• Эффективность обнаружения уязвимостей в реальных сценариях (точность, минимизация ложных срабатываний/пропусков)
• Скорость выполнения анализа 
• Автоматизация и интеграция 
• Архитектурная гибкость и масштабируемость 
• Наличие и качество рекомендаций по устранению выявленных уязвимостей 

Второй этап

Бизнес критерии
• Ориентация на потребности DevOps/SecOps команд 
• Качество отчетности и UX 

Технические критерии
• Глубина анализа уязвимостей 

Критерии по выступлению
• Соблюдение единого стиля оформления 
• Соблюдение принципов структурности 
• Тема решения раскрыта полностью 
• Инновационность или творческий подход 
• Ответы на вопросы: лаконичность, аргументированность, корректность 

Третий этап

• Финальный этап оценки предполагает дополнительную всестороннюю оценку решений по критериям первого и второго этапов.