Что такое HTTPOnly cookie

HTTPOnly cookie это обычная cookie с дополнительным атрибутом HttpOnly. Сервер отправляет ее в ответе через Set-Cookie, а браузер сохраняет и отправляет обратно по правилам cookie.

Главное отличие для frontend-кода такое. Эта cookie не видна в document.cookie. Если на странице появится вредный скрипт, он не сможет просто прочитать токен и отправить его злоумышленнику.

Но cookie не исчезает для HTTP. Если запрос подходит по домену, пути, сроку жизни, SameSite и другим правилам, браузер приложит ее к запросу автоматически.

Хорошая короткая формулировка может звучать так:

HTTPOnly cookie это cookie, недоступная для JavaScript. Она помогает не дать XSS-скрипту украсть значение сессии или токена через document.cookie. Но она все равно отправляется браузером в запросах, поэтому для безопасности нужны еще Secure, SameSite, CSRF-защита и нормальная защита от XSS.

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

Пример ответа сервера:

Set-Cookie: refreshToken=abc123; HttpOnly; Secure; SameSite=Lax; Path=/auth/refresh; Max-Age=604800

В frontend-коде вы не сможете сделать так:

// Плохая идея: HttpOnly cookie так не читается
const token = document.cookie
  .split("; ")
  .find((row) => row.startsWith("refreshToken="));

Такой код не найдет refreshToken. Если на нем построить авторизацию, UI может уйти в вечный loading, начать повторять запросы или ошибочно показать logout. Надежнее считать сервер источником правды. Отправьте запрос с cookie, получите профиль или 401, затем обновите состояние интерфейса.

Если архитектура строится на HTTPOnly cookie, frontend не должен доставать токен и вручную собирать Authorization. Он должен отправлять запросы так, чтобы браузер мог приложить cookie. Сервер должен проверить сессию и вернуть понятный статус, например 401.

Для same-origin API браузер обычно сам отправит cookie в запросе. Для запросов на другой origin часто нужно явно включить credentials на клиенте и разрешить их на сервере.

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

Практический риск простой. Если забыть credentials, пользователь будет выглядеть неавторизованным, хотя сессия есть. Не превращайте это в бесконечный retry. Покажите нормальное состояние ошибки или предложите войти заново после ответа 401. Если открыть CORS слишком широко, можно получить дыру в безопасности. Для запросов с credentials сервер не должен отвечать wildcard-значением Access-Control-Allow-Origin: *.

На интервью полезно говорить не ставим все флаги и готово, а объяснять роль каждого флага. HttpOnly защищает от чтения cookie скриптом. Secure снижает риск перехвата в сети. SameSite помогает с кросс-сайтовой отправкой cookie.

Для auth-cookie обычно стоит начинать с максимально строгих настроек, а затем ослаблять их только под реальный сценарий. Например, интеграция с внешним доменом, SSO или платежный callback могут потребовать более аккуратной настройки SameSite.

Если backend хранит авторизацию в HTTPOnly cookie, frontend должен строить UX вокруг серверного статуса, а не вокруг чтения токена. Например, после загрузки приложения можно запросить /me, получить профиль или 401, и по этому состоянию показать интерфейс. На время запроса показывайте отдельный loading state, чтобы не мигал приватный экран и не появлялся ложный logout.

Это также влияет на logout. Недостаточно удалить состояние в React. Нужно вызвать endpoint, который сбросит cookie через Set-Cookie с истекшим сроком или пустым значением. Иначе браузер продолжит отправлять старую cookie, если она еще действительна. После logout отмените или игнорируйте устаревшие запросы к профилю, чтобы поздний ответ не вернул пользователя в авторизованное состояние.

Еще один вывод: не храните копию чувствительного токена в localStorage для удобства. Так вы разрушаете смысл HTTPOnly и возвращаете риск кражи токена через XSS.