Как приложение узнает, что пользователь авторизован при каждом запросе

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

Понимаете ли вы, что HTTP не хранит состояние и сервер ничего «не помнит»: доказательство входа приходит с каждым запросом. Для QA следом идёт главное: как вы это проверите и где тут обычно прячутся дыры.

Как отвечать

Два основных механизма:

• сессия на сервере: после входа сервер создаёт запись сессии и отдаёт её идентификатор в cookie. Браузер сам прикладывает cookie к каждому запросу, сервер находит сессию в хранилище и понимает, кто это;
• токен: чаще всего JWT в заголовке Authorization: Bearer <token>. Сервер проверяет подпись и срок exp и берёт данные пользователя прямо из токена, обычно без похода в базу. Короткий access-токен обновляется через долгоживущий refresh-токен.

Разведите аутентификацию (кто вы) и авторизацию (что вам можно), а с ними коды: 401 значит «не узнали, войдите», 403 значит «узнали, но нельзя».

Дальше то, что интервьюер хочет услышать от тестировщика, список проверок:

• без токена: запрос без токена или cookie получает 401, а не данные;
• просроченный токен: сервер отвечает 401, клиент обновляет токен и повторяет запрос незаметно для пользователя;
• подделка: токен с изменённым payload или подписью отклоняется;
• чужой ресурс: пользователь A со своим токеном не получает данные пользователя B, подставив чужой id (IDOR);
• выход: после логаута старая сессия перестаёт работать;
• флаги cookie: у сессионной cookie стоят HttpOnly, Secure и SameSite.

Инструменты: вкладка Network в DevTools, Postman или Burp Suite для подмены заголовков, декодер JWT, чтобы посмотреть payload.

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

Считают, что JWT зашифрован. Он лишь подписан и закодирован в base64url, содержимое читает любой, поэтому пароли и персональные данные туда не кладут.

Путают 401 и 403 или принимают 200 с пустым телом за корректный отказ.

Не проверяют выход из системы. С JWT без чёрного списка токен продолжает работать до истечения exp, даже если на клиенте его удалили, и это стоит обсудить с разработчиками как риск.