Выявление чувствительных данных в ответах API

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

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

По данным Роскомнадзора, за 2024 год ведомство зафиксировало 135 фактов утечек персональных данных, содержащих более 710 млн записей. Согласно отчёту InfoWatch, реальный объем скомпрометированных данных в России достиг 1,58 млрд записей. Значительная часть этих утечек происходит не через взлом основных баз, а через «вторичные» хранилища и API-ответы, которые компании вообще не воспринимают как зону риска.

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

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

Ключевые факторы уязвимости API

Разрастание API. Разработка API различными командами приводит к появлению плохо документированных и неуправляемых теневых API. Они становятся всё более «слепой зоной» для организаций и приводят к потенциальным нарушениям.

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

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

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

T-Mobile: 37 млн клиентов за одну уязвимость

В 2023 году компания T-Mobile раскрыла сведения об инциденте, в результате которого злоумышленники смогли загрузить персональные данные 37 млн клиентов. Для совершения атаки использовались недоработки в реализации API, доступного без авторизации. В руки атакующих попали ФИО, адрес, email, номер телефона, дата рождения и другие чувствительные данные. Вредоносная активность была обнаружена 5 января, но извлечение данных производилось с 25 ноября 2022 года — злоумышленники имели доступ к данным почти полтора месяца.

Google+: уязвимость, затронувшая 52,5 млн пользователей

В 2018 году Google объявила об обнаружении уязвимости в API социальной сети Google+. Тогда под угрозой оказались данные 52,5 млн пользователей. API возвращал больше данных, чем предполагалось, позволяя разработчикам сторонних приложений получать доступ к личной информации пользователей, которую те не планировали раскрывать.

Volkswagen: BOLA-уязвимость в дилерском центре

В приложении для владельцев автомобилей Volkswagen в Индии обнаружили критическую уязвимость. Чтобы зарегистрировать подержанный автомобиль, нужно было ввести 4-значный идентификатор, который легко подбирался, открывая доступ к данным других владельцев. Эта уязвимость относится к категории Broken Object Level Authorization (BOLA) и является классическим примером того, как недостаточная проверка прав доступа на уровне объектов приводит к утечке персональных данных.

Утечки через AI-платформы: новый вектор угроз

В марте 2025 года из AI-платформы MyLovely.ai утекли данные более чем 106 000 аккаунтов. Утекли не пароли и не хэши, а полные тексты промптов интимного содержания, привязанные к email-адресам. Это не единичный случай — волна утечек данных AI-платформ (от DeepSeek до companion-сервисов) показывает системную дыру: утекают не credentials, а мысли.

Согласно исследованию ГК «Солар», в 2025 году объём данных, отправляемых в общедоступные нейронные сети из российских компаний, вырос в 30 раз. При этом около 60% российских организаций до сих пор не имеют формализованных политик, регулирующих работу с ИИ-сервисами. Сотрудники массово загружают в нейронные сети конфиденциальную информацию, не осознавая рисков.

1. Утечка данных через ответы API (Excessive Data Exposure)

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

Как это выглядит на практике:

```json
{
    "id": 123,
    "name": "Иван Петров",
    "email": "ivan@example.com",
    "phone": "+7-999-123-45-67",
    "password_hash": "5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8",
    "address": "ул. Ленина, д. 1",
    "passport_series": "1234",
    "passport_number": "567890"
}
```

Клиентское приложение может отображать только имя и email, но злоумышленник, захвативший ответ, получит все данные.

2. Broken Object Level Authorization (BOLA)

Система контролирует, что пользователь аутентифицирован, но не проверяет, имеет ли он право работать именно с запрашиваемым объектом. Злоумышленнику достаточно изменить идентификатор в запросе, чтобы получить доступ к конфиденциальным данным. На эту уязвимость приходится 27% всех атак на API.

3. Broken Object Property Level Authorization (BOPLA)

Даже если пользователь имеет доступ к объекту, он может не иметь права видеть или изменять конкретные свойства этого объекта. Например, обычный пользователь может увидеть поле `is_admin` или `internal_notes`.

4. Отсутствие или слабая аутентификация и авторизация

Доступ к API без проверки прав или с использованием слабых механизмов (например, статических токенов). Злоумышленник подбирает токен и получает доступ к данным пользователей.

5. Некорректная проверка входных данных

API не фильтрует входные параметры, что позволяет внедрить SQL-инъекцию или выполнить произвольный код. Запрос `GET /api/user?id=1 OR 1=1` может вернуть данные всех пользователей.

6. Небезопасная конфигурация

Открытые эндпоинты, стандартные учетные записи, отладочная информация в ответах. Эндпоинт `/api/debug` может возвращать логи с паролями.

1. Аудит API-ответов

Регулярно анализируйте, какие данные реально возвращают ваши API-эндпоинты. Проверяйте наличие:

- Хешей паролей и токенов аутентификации

- Внутренних идентификаторов

- Персональных данных (PII)

- Деталей инфраструктуры

- Финансовой информации

2. Использование автоматизированных инструментов

Специализированные инструменты могут сканировать API-ответы на наличие чувствительных данных. WAF (Web Application Firewall) анализирует входящий трафик на уровне HTTP-запросов и фильтрует вредоносные запросы. WAF способен блокировать такие атаки, как SQL-инъекции и XSS, хотя не является панацеей.

3. Мониторинг и логирование

Введите детальные логи всех API-запросов и ответов (без чувствительных данных). Отслеживайте необычные паттерны: например, если один пользователь запрашивает данные сотен других пользователей, это может быть признаком атаки.

4. Тестирование безопасности

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

- Возвращают большие объемы данных

- Работают с чувствительной информацией

- Принимают данные от пользователей для обновления

5. Анализ трафика

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

1. Минимизация данных в ответах (Принцип наименьших привилегий)

Возвращайте клиенту только те данные, которые абсолютно необходимы для выполнения конкретной операции. Маскируйте чувствительные поля. Создавайте отдельные DTO (Data Transfer Objects) для разных сценариев использования.

2. Контроль доступа на уровне свойств

Реализуйте механизмы, которые проверяют права доступа не только к объекту в целом, но и к каждому его свойству. Используйте RBAC (Role-Based Access Control) или ABAC (Attribute-Based Access Control).

3. Использование современных протоколов аутентификации

Для повышения безопасности используйте современные протоколы, такие как OAuth 2.0, а также технологию JSON Web Tokens (JWT) для безопасного обмена данными. Внедрите многофакторную аутентификацию (MFA).

4. Шифрование данных

Шифрование данных играет ключевую роль в защите API. Применение шифрования на уровне передачи данных (TLS) защищает от перехвата и подмены данных. Шифрование на уровне хранения помогает защитить информацию при компрометации базы данных.

5. Ограничение частоты запросов (Rate Limiting)

Отсутствие лимитов на количество запросов позволяет провести DDoS-атаку или брутфорс. Настройка лимитов (например, 100 запросов в минуту на IP) и использование CAPTCHA помогают предотвратить автоматизированные атаки.

6. Регулярный аудит конфигурации

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

7. Внедрение безопасных процессов разработки

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

8. Обучение сотрудников

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

9. Инвентаризация API

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

10. Использование специализированных решений

Компания «Вебмониторэкс» уже несколько лет развивает средства защиты API в составе единой платформы на базе WAF. Её назначение — отражение веб-угроз, нарастающих на фоне внедрения генеративного искусственного интеллекта и больших языковых моделей.

С 30 мая 2025 года в России вступили в силу принципиальные изменения в статье 13.11 КоАП РФ. За нарушение правил обработки персональных данных общей категории можно получить штраф до 500 млн рублей, специальной категории — наказание в форме лишения свободы на срок до пяти лет.

Штрафы за утечки теперь зависят от объёма скомпрометированных данных:

- Утечка данных от 1 000 до 10 000 субъектов — от 3 до 5 млн рублей для юридических лиц

- Утечка данных от 10 000 до 100 000 субъектов — от 5 до 10 млн рублей

- Утечка данных свыше 100 000 субъектов — от 10 до 15 млн рублей

- При повторных нарушениях — оборотный штраф от 1 до 3% годовой выручки, но не менее определённой суммы

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

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

Ключевые выводы:

1. API — основной канал утечки данных. По данным исследований, значительная часть утечек происходит через API-ответы и «вторичные» хранилища.

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

3. Традиционные инструменты безопасности не всегда эффективны. WAF защищает от инъекций, но не от уязвимостей контроля доступа.

4. Теневые API — это «слепая зона» для организаций. Они возникают из-за высокой скорости разработки и отсутствия продуманной документации.

5. Правовые последствия серьезны. Штрафы за утечку персональных данных в России достигают 500 млн рублей.

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

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

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