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

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

Что проверить в первую очередь

  • Проверьте, какие endpoint возвращают данные без фильтра по организации.
  • Определите типы токенов: пользовательские, сервисные, интеграционные, админские.
  • Временно ограничьте опасные методы или scopes, если есть риск утечки.
  • Снимите аудит обращений за последние дни по токенам и организациям.

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

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

  • Запросы к базе фильтруют данные по user_id, но не по organization_id.
  • Middleware авторизации проверяет токен, но не связывает его с tenant-контекстом.
  • Сервисный токен получил глобальный scope вместо ограниченного набора прав.
  • Админские права используются для обычной интеграции.

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

  • Возьмите тестовый токен одной организации и запросите ресурс другой организации.
  • Проверьте все методы с параметрами id: заказ, счет, файл, пользователь, проект.
  • Найдите SQL-запросы без tenant_id или проверки принадлежности ресурса.
  • Проверьте scopes токена и то, как они интерпретируются в коде.
  • Проверьте фоновые задачи и webhook-обработчики: они тоже могут обходить RBAC.

Как исправить

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

  • Добавьте обязательный tenant-контекст для каждого API-запроса.
  • Проверяйте принадлежность ресурса организации перед чтением, изменением и удалением.
  • Разделите scopes: чтение, запись, платежи, файлы, администрирование.
  • Перевыпустите токены, которые могли получить лишние права.
  • Добавьте аудит доступа к чужим ресурсам и алерт на попытку нарушения изоляции.

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

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

Как проверить результат

  • Токен организации A не видит и не меняет ресурсы организации B.
  • Все endpoint с id возвращают 404 или 403 для чужого ресурса.
  • Тесты покрывают чтение, изменение, удаление и массовые списки.
  • В логах виден tenant-контекст каждого API-запроса.

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

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

Как не допустить повторения

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

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

  • Ссылку на проблемную страницу, кабинет, заказ, интеграцию или API-метод.
  • Точное время ошибки и пример пользователя, товара, платежа или запроса.
  • Скриншот, текст ошибки, лог веб-сервера, приложения или webhook-события.
  • Краткое описание ожидаемого поведения: что должно было произойти вместо ошибки.

Частые вопросы

Что опаснее: чужое чтение или чужая запись?

Оба варианта опасны. Чтение ведет к утечке данных, запись может изменить заказы, финансы и настройки другой организации.

Нужно ли уведомлять клиентов?

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

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

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

Итог

Изоляция организаций должна быть встроена в модель доступа, запросы и тесты. Я могу проверить API, закрыть лишние права токенов и настроить безопасный multi-tenant доступ.