Как хранятся куки на сервере
Что проверяют
Это вопрос с подвохом: куки на сервере не хранятся, они живут в браузере. Интервьюер смотрит, заметите ли вы это и объясните ли, что на сервере лежит на самом деле. Следом обычно спрашивают про HttpOnly, SameSite и где держать токен авторизации.
Как отвечать
Механика: сервер отправляет заголовок Set-Cookie, браузер сохраняет куку у себя и сам добавляет её в заголовок Cookie к каждому подходящему запросу по домену и пути. Сервер ничего не запоминает, он каждый раз читает то, что прислал браузер.
На сервере хранится сессия, если она есть. Два подхода:
- сессия по идентификатору: в куке только случайный id, данные на сервере. Память процесса годится для разработки, при нескольких инстансах и рестартах нужен Redis или база. Выход из системы это удаление записи, и сессия гарантированно умирает;
- данные в самой куке: подписанная или зашифрованная кука, например JWT. Сервер хранит только ключ, но отозвать такую сессию до истечения срока без отдельного списка отзыва нельзя.
Атрибуты, которые стоит назвать:
HttpOnly: кука недоступна изdocument.cookie, XSS-скрипт её не прочитает;Secure: только по HTTPS;SameSite:Strict,LaxилиNone. Без атрибута Chrome и другие браузеры на Chromium считаютLax, аNoneработает только вместе сSecure;Max-AgeилиExpires: без них кука сессионная и живёт до закрытия браузера;DomainиPath: где кука отправляется. Префикс__Host-запрещаетDomainи требуетSecureиPath=/.
Со стороны фронтенда: запрос на другой origin через fetch отправит куки только с credentials: "include", а сервер должен ответить Access-Control-Allow-Credentials: true и конкретным origin вместо *. На одну куку браузеры дают около 4 КБ.
Где спотыкаются
Отвечают, что куки это файлы на сервере, или путают куку с сессией.
Считают, что HttpOnly защищает от CSRF. Он защищает от чтения скриптом, а от подделки запросов защищают SameSite и CSRF-токены.
Держат сессии в памяти Node-процесса и удивляются, что пользователей разлогинивает после деплоя и при балансировке между инстансами.