Как правильно хранить токен во Frontend

Хороший ответ начинается не с названия хранилища, а с риска. Токен авторизации обычно работает как ключ к API. Если его украли, злоумышленник может делать запросы от имени пользователя, пока токен не истечет или не будет отозван.

Во frontend чаще сравнивают три варианта: Web Storage, память приложения и cookie. У каждого варианта своя цена. localStorage переживает перезагрузку страницы, но доступен JavaScript. Память приложения меньше подходит для кражи через простое чтение storage, но теряется при reload. HttpOnly cookie скрывает токен от JavaScript, но автоматически отправляется браузером и требует CSRF-защиты.

На интервью лучше не говорить, что токен всегда нужно хранить только в одном месте. Сильнее звучит так: вы выбираете вариант под угрозы и архитектуру. Это показывает, что вы понимаете компромисс, а не просто запомнили один совет.

Для типичного веб-приложения безопасная отправная точка такая: refresh token хранить в HttpOnly, Secure cookie, access token делать короткоживущим. Access token можно держать в памяти, если API требует заголовок Authorization. Если приложение использует cookie-сессию, access token как отдельная строка на клиенте может вообще не понадобиться.

Важно не обещать абсолютной защиты. HttpOnly cookie не дает прочитать токен, но если на странице есть XSS, вредный скрипт может нажимать кнопки, отправлять формы и вызывать API в рамках текущей сессии. Поэтому хранение токена снижает ущерб, но не заменяет защиту от XSS.

Если вам нужно привести пример, покажите плохой вариант и сразу назовите последствие. Плохой пример выглядит так:

// Плохо: токен доступен любому JavaScript на странице.
localStorage.setItem("access_token", token);

const token = localStorage.getItem("access_token");
fetch("/api/profile", {
  headers: { Authorization: `Bearer ${token}` },
});

Проблема не в самом fetch. Если появится XSS, вредный скрипт прочитает ключ access_token, отправит токен наружу и злоумышленник сможет дергать API уже со своего устройства. Еще один практический баг: frontend может продолжать считать пользователя авторизованным, пока токен лежит в storage, даже если сервер уже отозвал сессию.

Безопаснее сделать access token короткоживущим и держать его в памяти, а refresh token выдавать сервером через HttpOnly cookie. В обертке над запросами не теряйте существующие заголовки и отдельно обрабатывайте 401.

// Идея безопаснее: access token живет в памяти и не переживает закрытие вкладки.
let accessToken: string | null = null;

export function setAccessToken(token: string) {
  accessToken = token;
}

export function clearAccessToken() {
  accessToken = null;
}

export async function apiFetch(input: RequestInfo, init: RequestInit = {}) {
  const { headers: initHeaders, ...rest } = init;
  const headers = new Headers(initHeaders);

  if (accessToken) {
    headers.set("Authorization", `Bearer ${accessToken}`);
  }

  const response = await fetch(input, {
    ...rest,
    headers,
    credentials: "include", // если refresh cookie нужна этому запросу
  });

  if (response.status === 401) {
    clearAccessToken();
    // Здесь же сбросьте auth state в UI и запустите refresh или logout flow.
  }

  return response;
}

Это не делает приложение неуязвимым. При XSS вредный код все равно может вызывать API в открытой сессии. Но при обычной перезагрузке страницы токен исчезает из памяти, а долгоживущий refresh token не доступен через JavaScript, если сервер выдал его как HttpOnly cookie.

Если вы говорите про cookie, назовите флаги и зачем они нужны. HttpOnly запрещает доступ через document.cookie. Secure заставляет отправлять cookie только по HTTPS. SameSite ограничивает отправку cookie в cross-site сценариях.

Пример серверной установки cookie:

res.cookie("refresh_token", refreshToken, {
  httpOnly: true,
  secure: true,
  sameSite: "lax",
  path: "/auth/refresh",
  maxAge: 1000 * 60 * 60 * 24 * 7,
});

path не является полноценной границей безопасности, но помогает не отправлять refresh token на каждый endpoint. Для запросов, которые меняют состояние, все равно нужны серверные проверки. Обычно это CSRF-токен в заголовке плюс проверка Origin или Referer.

Автоматическое обновление токена стоит описывать аккуратно. Наивный interceptor часто создает гонки. Пять запросов получают 401, каждый запускает refresh, часть запросов повторяется со старым токеном, сеть забивается лишними запросами, а UI показывает пользователя авторизованным после провала обновления.

Хорошая формулировка для интервью:

Я бы сделал один refresh-запрос на группу параллельных 401, ограничил повтор исходного запроса одним разом и при ошибке refresh очистил состояние авторизации. Так приложение не уходит в бесконечный цикл и не показывает пользователю приватный UI без валидной сессии.

CSP полезна как дополнительный слой против XSS. Она может запретить inline-скрипты и ограничить источники скриптов. Но CSP не заменяет безопасный рендеринг данных и не исправляет уже выданный токен, который доступен JavaScript.

CORS нужен, чтобы браузер контролировал чтение ответов между origin. Но CORS не является способом хранения токена и не должен быть главным ответом на вопрос про токены. Не рассчитывайте, что CORS исправит XSS внутри вашего origin или заменит CSRF-защиту для cookie. Сервер обязан проверять авторизацию на каждом запросе, а не полагаться на то, что frontend не покажет кнопку.

Сильный ответ можно закончить так: я уменьшаю вероятность кражи токена, ограничиваю срок его жизни, защищаю refresh flow, закрываю CSRF для cookie и не отдаю секреты в клиентское состояние.