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

Материал будет полезен руководителям и специалистам по информационной безопасности, AppSec-командам, архитекторам, DevOps-инженерам и владельцам цифровых продуктов — всем, кто работает с микросервисами, мобильными приложениями, личными кабинетами, партнерскими интеграциями и внутренними платформами.

Начнем с кейса

Представим типичный аудит перед тестированием на проникновение или внедрением API Gateway. На архитектурном комитете команда уверенно говорит: «В промышленной среде у нас 214 API-эндпоинта. Всё описано в Swagger, основные маршруты заведены в API Gateway». Через неделю команда информационной безопасности поднимает журналы доступа на обратном прокси-сервере (reverse proxy) и видит уже 327 уникальных маршрутов. Ещё несколько десятков находятся в конфигурациях Ingress для Kubernetes, но не проходят через API Gateway. Часть из них вызывает мобильное приложение, часть — внутренние сервисы, часть — старый партнерский интеграционный контур, о котором уже никто не помнит.

В этот момент вопрос «сколько у нас API?» перестаёт быть справочным. Он превращается в расследование.

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

Так появляются Shadow API — теневые API. Они не обязательно плохо спроектированы или небезопасно написаны. Риск в другом: их нет в официальном списке, у них нет понятного владельца, они не попали в область тестирования, не покрыты проверками безопасности, по ним не настроены уведомления, а иногда они вообще обходят WAF и API Gateway.

API нельзя защитить, если вы не знаете, что он существует.

Что считать теневым API

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

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

Zombie API — это бывший легитимный API, который уже должен был быть выведен из эксплуатации, но фактически продолжает работать. Типичный пример — /api/v1/payment/confirm, который заменили на /api/v2/payment/confirm, но старую версию не отключили, потому что «вдруг кто-то ещё пользуется».

Shadow parameters — это ситуация, когда сама точка доступа описана, но в реальности принимает параметры, которых нет в спецификации. Например, в OpenAPI указан только customer_id, а в промышленной среде тот же метод также реагирует на debug=true, role=admin или include_internal=true.

Вот как это может выглядеть вживую:

GET /api/v1/users/{id}
GET /internal/users/export?id=123
GET /debug/customer/profile?user_id=123&include_internal=true

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

OWASP относит эту проблему к категории API9:2023 Improper Inventory Management — некорректное управление инвентарем API. Суть риска проста: если у компании нет актуального реестра и понятной стратегии вывода старых версий из эксплуатации, в инфраструктуре продолжают жить не обновляемые системы, появляются лишние каналы доступа к данным и маршруты API, случайно доступные извне. OWASP отдельно отмечает, что микросервисная архитектура, облачные среды и Kubernetes упрощают развертывание API, но усложняют контроль их фактической доступности.

Реальных API больше, чем в реестре

Если из всех рыночных чисел оставить одно, я бы оставил это: Cloudflare в 2024 API Security & Management Report сравнил self-reported API endpoints с тем, что обнаружили алгоритмы машинного обучения по реальному трафику. Разница составила 30,7%. То есть компании в среднем имели почти на треть больше API endpoint, чем думали сами.

Это важнее, чем кажется. Проблема не в том, что кто-то забыл обновить табличку в Confluence. Проблема в системном расхождении между тем, что организация считает своим API-ландшафтом, и тем, что реально отвечает на запросы.

Для контекста: по данным того же Cloudflare, на API приходилось около 57% динамического интернет-трафика. API давно перестали быть «технической прослойкой». Для внешнего мира API часто и есть приложение: через него создают заказы, получают персональные данные, проводят платежи, управляют аккаунтами и интегрируются с партнерами

Более свежие данные Salt Labs за 2025 год показывают, что проблема не стала менее острой. 99% респондентов сообщили, что за последние 12 месяцев сталкивались с проблемами безопасности API. При этом только 15% выразили высокую уверенность в точности своего API-инвентаря, и лишь 20% непрерывно отслеживают API. Это хорошо объясняет, почему ручной реестр перестаёт работать: когда поверхность меняется с такой скоростью, список API устаревает не «со временем», а в момент следующей поставки изменений.

Как одна забытая дверь превращается в инцидент

Один из недавних примеров — инцидент 700Credit в 2025 году. Компания работает с кредитными проверками и идентификацией клиентов для автодилеров, а её сервисы связаны с большим числом партнёрских интеграций. Согласно открытым источникам, злоумышленники сначала получили доступ к системе одного из интеграционных партнёров, а затем использовали API, через который можно было обращаться к данным клиентов.

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

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

Такие истории всё меньше похожи на исключение. По данным Imperva/Thales, только за первую половину 2025 года было зафиксировано более 40 тысяч API-инцидентов. Среди атакуемых зон — API доступа к данным, API оплаты, методы аутентификации, а также теневые или неправильно настроенные точки доступа.

Главная неприятность таких атак в том, что они часто выглядят как обычные HTTP-запросы. Не обязательно будет SQL-инъекция, Shell пейлоад или Noise эксплойт известной уязвимости. Злоумышленник может просто менять параметры, вызывать метод слишком часто, обращаться к данным в неправильном контексте или использовать API, который не должен был быть доступен в таком виде.

Для WAF это может выглядеть как корректный запрос. Для бизнес-системы — как обычная операция. Для команды безопасности — как инцидент, который станет заметен только после массовой выгрузки и анализа данных.

Безопасность API на российском рынке

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

Отраслевые отчеты показывают, что API всё чаще становятся самостоятельной целью для атак, особенно на прикладном уровне. Для интернет-магазина, банка, сервиса доставки или личного кабинета атака на API каталога, корзины, оплаты, авторизации или проверки статуса заказа — это не просто «недоступность сайта». Это остановка ключевого бизнес-процесса: пользователь не может оформить заказ, оплатить услугу, войти в личный кабинет или получить данные по операции.

На этом фоне сохраняется проблема утечек персональных данных. По данным InfoWatch, в 2025 году в российских организациях было зарегистрировано 739 инцидентов утечек информации ограниченного доступа, а количество скомпрометированных записей персональных данных составило 1,343 млрд. Важно: не каждая такая утечка связана с API. Но API всё чаще становится одним из каналов доступа к данным — через мобильные приложения, личные кабинеты, партнёрские интеграции, внутренние сервисы и автоматизированные обмены между системами.

Для российских компаний к техническому риску добавляется регуляторный. 152-ФЗ, требования к объектам критической информационной инфраструктуры и внутренние политики информационной безопасности предполагают, что организация понимает, где обрабатываются данные и какие системы имеют к ним доступ. Теневой API, который отдаёт персональные данные или позволяет выполнять операции в обход контроля, — это уже не просто пробел в документации. Это потенциальный инцидент информационной безопасности, юридический риск и прямой показатель незрелости процессов управления API.

Откуда берутся Shadow API

Парадокс в том, что Shadow API чаще всего появляются не из-за злого умысла и не из-за откровенной халатности. Они появляются как побочный эффект обычной разработки.

Команде нужно быстро отдать данные мобильному приложению — появляется отдельная точка доступа на стороне сервера. Партнёру нужно подключиться к пилотному проекту — поднимают временный маршрут. Аналитика просит выгрузку — добавляют внутренний метод /internal/export. Команда DevOps открывает временный Ingress для диагностики. Через месяц все переключаются на новые задачи, а точка доступа продолжает работать.

Дальше начинается самое интересное. API-эндпоинт уже кто-то использует, но никто не уверен, кто именно. Её страшно отключить. В документацию его не внесли. Владелец задачи перешёл в другую команду. Через полгода это уже не временное решение, а часть промышленного контура, которую никто толком не контролирует.

Типовые источники Shadow API выглядят так:

Микросервисы и быстрые релизы. Когда сервисов десятки или сотни, а релизы выходят каждый день, централизованный реестр быстро отстаёт от реальности. Особенно если регистрация API остаётся ручным процессом.

Мобильные приложения и SPA. Серверная часть для фронтенда часто живёт отдельно от основного API Gateway. Команда мобильной разработки знает свои точки доступа, но они не всегда попадают в общий каталог. При этом атакующему достаточно проанализировать сетевой трафик или декомпилировать приложение, чтобы увидеть реальные адреса.

Интеграции с подрядчиками. Временный API для пилотного проекта часто переживает сам пилот. Документация может остаться в переписке, ответственный — уволиться, а точка доступа — продолжить работать.

Legacy и старые версии. Старую версию не отключают, потому что «вдруг есть клиенты». Через год никто уже не знает, кто эти клиенты, но точка доступа продолжает принимать запросы.

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

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

Почему обычные инструменты их не ловят

Здесь обычно возникает вопрос: «У нас же есть API Gateway, WAF, OpenAPI, сканер и SIEM. Почему этого недостаточно?»

Потому что каждый инструмент видит только свой слой.

API Gateway — хороший инструмент управления, но не полноценный реестр API. Он видит только те маршруты, которые через него зарегистрировали. Shadow API часто живёт рядом: отдельный Ingress, устаревший хост, временный домен, прямое обращение одного сервиса к другому, партнёрская интеграция.

OpenAPI — это декларация. Он показывает, как API должен выглядеть по документации. Но только реальный трафик покажет, что действительно работает и принимает запросы.

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

Поэтому инвентаризацию API нельзя строить только на заявлениях команд. Ручной реестр API устаревает не «со временем». Он устаревает в момент следующей поставки изменений.

Как должен выглядеть нормальный API-инвентарь

Каталог API — это не список адресов.

Если в реестре есть только GET /users/{id}, этого недостаточно для управления риском. Нужна карточка точки доступа API, которая отвечает на практические вопросы:

• где работает точка доступа: промышленная среда, тестовая среда, среда приемки, среда разработки;

• кто владелец: команда, сервис, бизнес-направление;

• какой метод и путь используются: GET, POST, PUT, DELETE, приведенный к единому виду путь;

• какой тип API используется: REST, GraphQL, gRPC, WebSocket, SOAP;

• какой уровень доступности у API: публичный, партнерский, внутренний, межсервисный;

• через что проходит сетевой трафик: API Gateway, WAF, Ingress;

• какие данные обрабатываются: персональные данные, платежные данные, коммерческая тайна, технические данные;

• какая аутентификация и авторизация используются;

• есть ли OpenAPI-спецификация или другой формализованный контракт;

• когда точка доступа последний раз вызывалась;

• какие клиенты её используют;

• есть ли старая версия;

• есть ли план вывода из эксплуатации.

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

Как начать искать Shadow API

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

Для старта не нужна большая платформа и многомесячный проект. Достаточно провести первый цикл обнаружения и сверки API.

1. Выгрузить официальные источники. Соберите список API из API Gateway, OpenAPI/Swagger, коллекций Postman, Confluence, CMDB и каталога сервисов.

2. Собрать инфраструктурные маршруты. Проверьте Kubernetes Ingress, service mesh, reverse proxy, балансировщики нагрузки, DNS-записи, сертификаты и правила межсетевых экранов.

3. Собрать фактическую картину по трафику. Возьмите журналы доступа с WAF, NGINX/Envoy, API Gateway, APM или SIEM хотя бы за 7–14 дней. Важно смотреть не только внешний периметр, но и внутренний сетевой трафик, если это возможно.

4. Привести пути к единому виду. Маршруты GET /users/123 и GET /users/456 должны превратиться в GET /users/{id}. Иначе вы получите не инвентарь API, а шум из однотипных адресов.

5. Сравнить фактическую картину с документацией. Всё, что есть в трафике, но отсутствует в официальных источниках, — кандидат в Shadow API. Всё, что есть в документации, но давно не вызывается, — кандидат в Zombie API.

6. Назначить владельцев. Точка доступа без владельца — отдельный риск. Если никто не может объяснить, зачем она нужна, это повод не просто добавить её в таблицу, а начать разбор.

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

8. Встроить контроль в CI/CD. Новая точка доступа должна попадать в инвентарь не через месяц после выпуска, а в момент появления в коде, спецификации или фактическом трафике.

Что делать с найденными API

У найденного Shadow API обычно четыре судьбы.

Зарегистрировать и оставить. API нужен бизнесу, но раньше жил вне процесса управления. Добавляем владельца, описание, класс обрабатываемых данных, требования к аутентификации и авторизации, мониторинг и проверки безопасности.

Ограничить доступ. Точка доступа нужна, но не должна быть публичной. Закрываем её через API Gateway, сетевые политики, mTLS, список разрешенных источников, VPN или межсервисную аутентификацию.

Исправить. API нужен, но реализован небезопасно: отдает лишние данные, не проверяет права доступа к объекту, не ограничивает частоту запросов, использует слабую авторизацию или устаревшую бизнес-логику.

Удалить. Точка доступа не используется, владелец не найден, бизнес-ценности нет. Значит, её нужно выводить из эксплуатации, а не оставлять «на всякий случай».

Для руководства это лучше переводить в метрики, а не в абстрактные риски:

• сколько точек доступа API обнаружено всего;

• сколько найдено только в фактическом трафике;

• сколько отсутствует в OpenAPI;

• сколько не имеет владельца;

• сколько публично доступно;

• сколько работает с персональными или платёжными данными;

• сколько обходит API Gateway или WAF;

• сколько старых версий продолжает отвечать на запросы;

• сколько API не вызывались 30, 60 или 90 дней;

• сколько точек доступа закрыто, исправлено или удалено за период.

Главная метрика зрелости — не общее количество API. Главная метрика — доля активных API, которые находятся под управлением.

Вместо вывода

Shadow API — это не экзотическая угроза и не редкая ошибка отдельной команды. Это структурное следствие современной разработки: быстро, распределенно и через API.

Разработка создаёт новые интерфейсы каждый день. Безопасность и эксплуатация часто узнают о них позже. Документация отстаёт от кода. API Gateway видит не всё. Тестирование на проникновение проверяет только то, что попало в область проверки. В результате компания защищает не всю совокупность API, а только ту часть, которую смогла увидеть.

Именно поэтому мы в CodeScoring решили развивать направление API Security. Наша команда видит, что проблема становится всё более актуальной для российских компаний: API становится больше, архитектуры усложняются, требования к защите данных растут, а отечественного программного обеспечения, которое помогает системно обнаруживать, инвентаризировать и контролировать API, пока немного. Поэтому мы усилили команду и готовим новый продукт, который будет помогать компаниям видеть реальную картину своих API — от кода и инфраструктуры до фактического сетевого трафика.

Но честный первый шаг — не покупка очередного инструмента и не написание нового регламента. Первый шаг — проверить, насколько ваша картина совпадает с реальностью.

Возьмите зеркало сетевого трафика или журналы доступа за неделю. Приведите маршруты к единому виду. Сравните их с официальным реестром и OpenAPI. Если списки совпадут — поздравляю, у вас редкий уровень зрелости. Если нет — вы наконец увидите не те API, которые должны существовать по документации, а те, которые действительно существуют.

И именно с этого момента разговор про API Security становится предметным.