Если API отдает персональные данные в лишних полях, frontend может даже не показывать их пользователю, но данные уже доступны в Network и могут попасть в логи, расширения или сторонний код.

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

Коротко: что сделать

  • Проверить JSON-ответы в Network
  • Найти лишние поля: email, телефон, роли, токены, внутренние ID
  • Проверить serializers/resources/DTO
  • Проверить разные роли пользователей
  • Проверить логи и кеш API

Основные причины

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

  • Контроллер возвращает ORM-модель целиком
  • Serializer один для админки и публичного API
  • Права проверяются на endpoint, но не на уровне полей
  • Debug-поля попали в production
  • Кеш API хранит расширенный ответ и отдает его другим сценариям

Пошаговая диагностика

Диагностику удобнее вести на одном воспроизводимом примере: один пользователь, один заказ, один запрос, один файл или одно событие. Так проще отделить реальную причину от случайных совпадений.

  • Сравнить ответ API для владельца и чужого пользователя
  • Проверить все поля JSON и вложенные объекты
  • Посмотреть OpenAPI/документацию, если она есть
  • Проверить mobile API отдельно от web
  • Проверить GraphQL или related endpoints, если они используют те же модели

Как исправить проблему

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

  • Ввести DTO или resource classes для публичных ответов
  • Разделить admin и public serializers
  • Добавить field-level authorization
  • Убрать tokens, secrets и служебные поля из JSON
  • Добавить тесты на отсутствие чувствительных полей

Безопасный план решения

Сначала закройте самые чувствительные поля: токены, пароли, cookies, телефоны, email, документы. Затем приведите весь API к явным контрактам ответов.

Чего не стоит делать

  • Не возвращать модель базы напрямую
  • Не надеяться, что frontend просто не покажет поле
  • Не кешировать персональный ответ как общий
  • Не логировать полный JSON с приватными данными

Что подготовить перед исправлением

  • URL endpoint
  • Пример ответа JSON
  • Какие роли имеют доступ
  • Какие поля считаются лишними
  • Framework backend

FAQ

Если поле не видно на странице, это утечка?

Да, если оно есть в ответе API, пользователь или скрипт может его прочитать.

Нужно ли менять базу?

Обычно нет. Нужно изменить слой выдачи данных: serializer, DTO, resource или query projection.

Как проверить регрессию?

Добавить тесты, которые явно запрещают чувствительные поля в публичном ответе.

Когда стоит обратиться за помощью

Обращаться стоит, если API работает с клиентами, заказами, личными кабинетами, платежами или интеграциями.

Итог

Проверьте ответы API, уберите лишние поля через DTO/serializer и добавьте тесты. Если нужно закрыть утечку персональных данных в API, пишите в Telegram @rabotator_support.