Как различали запросы разных пользователей

Что проверяют

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

Как отвечать

Начните с того, как было устроено у вас, и назовите механизм:

• сессия на cookie: в Django SessionMiddleware выдаёт sessionid, а AuthenticationMiddleware по нему кладёт пользователя в request.user. Состояние хранится на сервере, в базе или Redis, поэтому выход из системы срабатывает сразу;
• токен в заголовке: Authorization: Bearer .... В DRF это классы из DEFAULT_AUTHENTICATION_CLASSES, для JWT обычно djangorestframework-simplejwt; в FastAPI зависимость Depends(get_current_user) поверх OAuth2PasswordBearer;
• анонимные пользователи: анонимная сессия или идентификатор в cookie. IP для этого слабая опора: за одним NAT мобильного оператора сидят сотни людей.

Вторая половина задачи: различать не только пользователей, но и сами запросы. Для логов заводят X-Request-ID, кладут его в contextvars и добавляют в каждую строку через фильтр logging. В асинхронном коде threading.local для этого не годится, поэтому и нужен contextvars.

Если приложение стояло за nginx, скажите, как брали реальный IP: из X-Forwarded-For и только от доверенного прокси.

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

Где спотыкаются

Берут user_id из тела запроса или query-параметра и верят ему. Это прямой путь к IDOR: пользователь подставит чужой идентификатор и получит чужие данные. Идентификатор берётся только из проверенной сессии или токена.

Хвалят JWT за отсутствие состояния и не могут ответить, как разлогинить украденный токен. Нужны короткий срок жизни, refresh-токены и список отозванных.

Кладут текущего пользователя в глобальную переменную модуля. В асинхронном коде и под нагрузкой один запрос начинает видеть пользователя из другого.