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

Для SaaS, CRM, кабинетов и API это критичный риск доверия, договоров и конфиденциальности.

Коротко: каждый запрос должен проверять не только валидность token, но и принадлежность ресурса тому же tenant/project.

Почему возникает проблема

Проблема возникает, когда middleware проверяет только подпись token, но не сверяет project_id, tenant_id, scope, owner ресурса или кеширует права без учета проекта.

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

  • какие claims есть в token
  • проверяется ли project_id на каждом запросе
  • как устроены scope и роли
  • не кешируются ли права общим ключом
  • есть ли тесты на доступ к чужому проекту

Как я решаю такую задачу

Я проверяю путь авторизации от token до конкретной записи в базе.

  • воспроизвожу запрос с чужим token на тесте
  • проверяю middleware и ACL
  • добавляю проверку tenant/project
  • исправляю кеш прав
  • покрываю сценарий автотестом

Что подготовить

  • пример API-запроса
  • описание проектов и клиентов
  • доступ к backend-коду
  • структуру token без секретов
  • правила ролей

Сроки и риски

Сначала нужно закрыть опасный доступ, затем проверить похожие endpoint. В multi-tenant API такие ошибки часто повторяются в нескольких местах.

Чего лучше не делать

Не ограничивайтесь проверкой на frontend. Доступ должен запрещаться на backend и уровне API.

FAQ

Можно ли просто добавить project_id в URL?

Нет, его нужно еще сверять с token и правами пользователя.

JWT подпись валидна, почему это проблема?

Подпись доказывает token, но не дает право на любой проект.

Нужен ли аудит логов?

Да, чтобы понять, были ли реальные обращения к чужим данным.

Как не допустить регресс?

Добавить тесты на запрет доступа к чужому tenant.

Нужна похожая задача?

Напишите в Telegram @rabotator_support или оставьте заявку на сайте. Пришлите ссылку, пример ошибки и короткое описание того, как должно работать. Я посмотрю задачу, предложу безопасный план и скажу, какие доступы понадобятся.

Итог

API должен жестко изолировать проекты: валидный token одного клиента не должен открывать ресурсы другого клиента ни при каких параметрах запроса.