Что такое cookie

Cookie - это не просто файл в браузере и не полный аналог localStorage. Это механизм HTTP, который связывает небольшое значение с доменом и путем. Когда запрос подходит под эти ограничения, браузер сам добавляет cookie в запрос.

Типичный обмен выглядит так:

HTTP/1.1 200 OK
Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

После этого браузер может отправлять cookie в следующих запросах:

GET /api/me HTTP/1.1
Host: example.com
Cookie: sessionId=abc123

Для интервью главное вот что. Cookie удобны, когда серверу нужно узнавать пользователя между запросами. Но автоматическая отправка делает их чувствительными к настройкам безопасности и кросс-доменным правилам.

Короткий ответ может звучать так:

Cookie - это небольшие данные, которые браузер хранит для сайта и отправляет с подходящими HTTP-запросами. Их часто используют для сессий, авторизации, настроек и аналитики. Для авторизационных cookie важны HttpOnly, Secure, SameSite, срок жизни и область действия. На фронтенде я не считаю наличие cookie доказательством логина, а проверяю сессию по ответу сервера.

Такая формулировка сильнее, чем ответ cookie хранят данные пользователя. Вы сразу показываете механизм, применение, риск и практическое действие в UI.

На фронтенде не стоит говорить, что cookie всегда лучше или хуже Web Storage. Правильный выбор зависит от того, кто должен читать значение и должно ли оно автоматически уходить на сервер.

Например, тему интерфейса можно хранить в localStorage, если она нужна только после загрузки приложения. Но если сервер рендерит страницу и должен сразу отдать HTML в правильной теме, cookie может быть удобнее, потому что она придет вместе с запросом.

На собеседовании не нужно перечислять все возможные атрибуты cookie. Достаточно уверенно назвать те, которые влияют на безопасность, срок жизни и область действия. Так вы показываете, что думаете не только о синтаксисе, но и о последствиях для продукта.

Плохой пример для авторизации:

// Плохо: токен доступен любому JavaScript на странице.
document.cookie = `token=${token}; path=/`;

Если на странице появится XSS, злоумышленник сможет прочитать такую cookie через document.cookie и унести токен. Еще одна проблема в том, что фронтенд не может поставить HttpOnly. Поэтому сессионную cookie лучше выдавать с сервера через Set-Cookie.

Более безопасная схема:

Set-Cookie: sessionId=abc123; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600

Фронтенд в таком случае не читает сам секрет. Он делает запрос, обрабатывает статусы 200, 401, 403 и обновляет UI по ответу сервера. Например, показывает загрузку при проверке сессии, переводит пользователя на экран входа при 401 и не оставляет кнопку "Выйти" после неуспешного logout.

Не говорите, что наличие cookie в браузере само доказывает авторизацию. Источник правды находится на сервере. Cookie может устареть, быть удалена, не подойти по домену или не отправиться из-за настроек браузера. Поэтому UI должен уметь показать проверку сессии, обработать неавторизованный ответ и не показывать пользователю ложное состояние.

Частая frontend-ловушка выглядит так. API находится на другом origin, сервер прислал Set-Cookie, но пользователь остается неавторизованным. В таком сценарии нужно проверять не только код приложения, но и правила браузера.

Для fetch с cookie на другой origin часто нужен такой запрос:

await fetch("https://api.example.com/me", {
  method: "GET",
  credentials: "include",
});

Но одной настройки на фронтенде недостаточно. Сервер должен разрешить credentials в CORS, вернуть конкретный origin вместо *, а cookie должна иметь подходящие SameSite, Secure, Domain и Path. Если не проверить все части, можно долго искать баг в React, хотя проблема в HTTP-настройках. Практический симптом для пользователя это бесконечный loading, повторный запрос профиля или внезапный редирект на login после успешной формы входа.

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

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