Утечки данных через API: почему растет число инцидентов в бизнесе

Партнёрский API превратился в промышленный комбайн для выкачивания данных.

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

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

Масштаб угрозы: бизнес атакуют через легитимный трафик

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

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

Масштаб проблемы подтверждают отраслевые исследования. По аналитике Gartner, инцидент со скомпрометированным API приводит в среднем как минимум к десятикратному объёму утечки по сравнению с обычным кибератакой. Речь идёт об отдельной оценке, а не о законе природы: конкретная атака может дать больше или меньше. Но направление очевидно. Один автоматизированный сценарий способен обойти множество защитных барьеров, которые выстроены против единичного взлома.

Исследование Akamai API Security Impact Study зафиксировало API-инциденты у 84% опрошенных специалистов по безопасности за предшествующие 12 месяцев. Одновременно доля организаций с полной инвентаризацией API снизилась с 40% до 27%. Получается неприятная динамика: сами интерфейсы множатся, а доля компаний, понимающих, где они находятся и через какие данные проходят, сокращается.

Финансовый результат таких ошибок тоже измерим. Akamai оценивает среднюю стоимость устранения последствий инцидента безопасности API в США в $591 404. В эту сумму входят не только технические работы, но также расследование, уведомления, восстановление процессов и репутационные издержки.

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

Теневые и зомби-интерфейсы: слепые зоны корпоративной инфраструктуры

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

По данным отчёта Salt Security, около 30–40% всего пула API компании могут приходиться на теневые или устаревшие интерфейсы. При этом 99% организаций сталкивались с проблемами безопасности API за последние 12 месяцев. Здесь важно не превращать каждую неучтённую строку в трагедию: показатель отражает зрелость процесса управления API в целом. Но тридцать–сорок процентов неизвестных интерфейсов — слишком много поверхности, чтобы считать её несущественной.

Подобные маршруты остаются после миграции внутренних систем, интеграции партнёров, выпуска мобильных версий и объединения инфраструктуры. Старый сервис может продолжать работать, потому что от него зависит неочевидный процесс. Один разработчик помнит, зачем он нужен. Другой знает только URL. Третий уже уволился.

Полная инвентаризация API без проверки авторизации — это карта сокровищ без замков на дверях.

Инвентаризация не должна ограничиваться файлом со списком URL. Рабочий каталог должен содержать для каждого интерфейса:

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

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

Показатель полной инвентаризации в 27% показывает, что значительная часть компаний не может даже перечислить свои интерфейсы. Пока этот пробел существует, безопасник работает вслепую. Он настраивает мониторинг, покупает WAF, внедряет журналирование и не знает, какой из тысяч маршрутов остаётся доступным без авторизации.

BOLA, сломанная аутентификация и лишние данные в ответе

Обновлённый отраслевой стандарт рисков OWASP API Security Top 10 был опубликован в 2023 году. Среди ключевых причин утечек через API — BOLA, дефекты аутентификации и чрезмерное раскрытие данных, когда бэкенд возвращает клиенту полный JSON-объект.

BOLA, или Broken Object Level Authorization, возникает из-за ошибки в одном из двух уровней проверки прав. Авторизация на уровне роли отвечает на вопрос, может ли клиент вызвать метод API. Авторизация на уровне объекта отвечает на другой вопрос: имеет ли этот конкретный клиент право получить именно эту запись.

Если backend проверяет токен, HTTP-метод и общий доступ к endpoint, но не проверяет принадлежность объекта, менять идентификатор в запросе недостаточно сложно. Клиент остаётся авторизованным, формат запроса остаётся корректным, а ответ возвращает чужой объект. Классическая проверка «пользователь существует и токен валиден» здесь бессильна.

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

Валидный токен подтверждает, кто отправил запрос. Он не подтверждает, что у этого отправителя есть право получить возвращённые данные.

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

Третий сценарий выглядит почти безобидно: backend отдаёт клиенту больше полей, чем требуется приложению. Формально ответ успешный, формат корректный, ошибок нет. Но в полном объекте могут оказаться адрес, телефон, внутренние идентификаторы, признаки сегментации клиента или данные, которые не должны покидать сервер.

Вместо конкретного набора полей backend отдаёт «всё, что нашёл». После этого партнёрское приложение, скомпрометированный токен или автоматизированный скрипт получают данные в объёме, который приложению никогда не требовался. Это уже не уязвимость отдельного поля. Это архитектурный переизбыток доступа.

Автоматизация превращает дефект в утечку

Инцидент с DELL показывает, как это работает на практике. Скрипт собирал данные через партнёрский API, отправляя тысячи запросов в минуту. У API отсутствовали строгая верификация и rate limiting. Результатом стали 49 млн записей клиентов.

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

Восемь тысяч запросов могут быть нормальной активностью одного крупного клиента. Несколько тысяч запросов от партнёрского токена, которые возвращают разные записи и укладываются в лимит, вполне могут оказаться сбором. Без корректного baseline мониторинг видит «работу приложения», а не извлечение данных.

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

• клиента, партнёра или сервисный аккаунт;
• конкретный токен;
• endpoint и tenant;
• число возвращённых записей;
• суммарный объём ответа;
• частоту однотипных запросов к разным объектам.

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

Один IP-адрес также не является надёжной единицей контроля. Злоумышленник может менять адреса, а вредоносный код может выполняться из легитимной инфраструктуры. Лимиты стоит связывать с идентичностью API-клиента и контекстом доступа. Это сложнее, чем написать одно число в конфигурации. Зато результат работает.

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

Почему HTTPS, WAF и OAuth не закрывают всю поверхность

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

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

WAF анализирует запрос. Запрос с корректным токеном, разрешённым методом и допустимым форматом параметров выглядит чистым. При BOLA или BFLA нарушена бизнес-логика, а не синтаксис протокола. Некоторые сигналы вроде перебора могут сработать, но полагаться только на них — ошибка.

OAuth тоже часто становится источником ложной уверенности. Платформа выдала токен, backend проверил подпись, срок действия и набор scopes. На бумаге всё исправно. Если у токена слишком широкие права или объект доступен любому аутентифицированному клиенту, OAuth не мешает атаке. Он аккуратно выдаёт злоумышленнику законный пропуск.

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

Rate limiting — это не только защита от DDoS. Это ограничение скорости, с которой злоумышленник успевает опустошить ваш API.

Жёсткий порядок: где именно ломается защита

Ниже не список пожеланий из презентации. Это порядок работ, который имеет смысл для организации, где API уже обрабатывает клиентские данные.

1. Закрыть инвентаризацию и убрать зомби. Соберите реальные маршруты, версии, методы, владельцев, клиентов, способы аутентификации и категории данных. Интерфейс без владельца и срока жизни получает тот же статус, что и неизвестный сервер: изолируйте, проверьте и отключите. Новый endpoint не выходит в среду без записи в каталоге.

2. Проверять права на каждом объекте. Авторизация должна выполняться на сервере для каждого запроса: принадлежит ли объект клиенту или tenant, разрешена ли операция, допустим ли объём выборки. Значение идентификатора из запроса нельзя принимать как доказательство доступа. Проверки должны закрывать горизонтальный доступ между клиентами и вертикальный доступ между функциями.

3. Отделить партнёров от собственных сервисов. Для каждого партнёра нужны собственные идентичности, ограниченные scopes, срок действия и отдельная квота. Общий статический токен на десятки интеграций превращает отзыв одного доступа в перебор всех клиентов. Права партнёра должны соответствовать реальной задаче, а не возможностям, которые «пригодились когда-то».

4. Минимизировать ответ. Возвращайте только поля, необходимые конкретному сценарию. Ограничивайте размер страницы и количество записей в одной выборке. Полный JSON-объект удобен разработчику, пока не приходит запрос автоматического сбора. Поле, которого нет в ответе, нельзя похитить через этот endpoint.

5. Настроить многоуровневые лимиты. Считайте запросы отдельно по клиенту, токену, tenant, endpoint и объёму данных. Настройте пороги не только по частоте, но и по числу записей, размеру ответа, серии одинаковых ошибок и перебору разных идентификаторов. Лимит должен уменьшать ущерб, а не просто фиксировать факт перегрузки.

6. Сделать журналы пригодными для расследования. Фиксируйте субъекта доступа, идентификатор токена, маршрут, версию, проверяемый объект, tenant, статус, количество записей и объём ответа. Сопоставляйте отклонения с нормальным профилем клиента. Один сработавший сигнал не всегда означает взлом, но резкий рост объёма, тысячи одинаковых запросов и перебор идентификаторов требуют немедленной проверки.

7. Навести порядок в секретах. Включите сканирование секретов в репозиториях, ограничьте доступ к рабочим пространствам Postman, уберите токены из истории коммитов и автоматизируйте ротацию. Обнаруженный ключ считать скомпрометированным до подтверждённого отзыва. Ротация без ревизии прав оставляет злоумышленнику новый экземпляр того же доступа.

8. Проверять BOLA, BFLA, аутентификацию и избыточные ответы. Тестирование должно имитировать запросы разных клиентов к одним и тем же объектам, попытки вызова закрытых методов и получение полного набора полей вместо разрешённого. Отдельный регламент нужен на случай, если токен скомпрометирован: отзыв доступа, временное сужение квот, проверка журналов, определение затронутых данных и уведомление по применимым требованиям.

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

TLS, WAF, OAuth и API-шлюз остаются обязательными слоями. Их задача — закрыть канал, отсечь очевидные атаки, проверить клиента и централизовать политику. Глубокую защиту создают серверная авторизация каждого объекта, минимальный ответ, квоты, полноценная инвентаризация и журналы, по которым видно аномальный сбор.

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