flawopen.com/Справочник/JWT против cookie HttpOnly
JWT в localStorage или cookie HttpOnly: что безопаснее?
Для многих веб-приложений хорошей отправной точкой служит сессия под управлением сервера, передаваемая в cookie с атрибутом HttpOnly. JavaScript не может прочитать такую cookie, что затрудняет извлечение токена, но не нейтрализует XSS: внедрённый код того же источника всё ещё может отправлять аутентифицированные запросы и читать доступные странице данные.
Компромиссы безопасности
| Хранение / передача | Риск XSS | Поведение при CSRF | Отзыв |
|---|---|---|---|
localStorage bearer token | JavaScript того же источника может прочитать токен; XSS может украсть его или действовать от имени пользователя. | Не добавляется автоматически к межсайтовым запросам; XSS и CSRF на стороне клиента остаются рисками. | Самодостаточный JWT может оставаться действительным до истечения срока без проверки отзыва. |
HttpOnly cookie | JavaScript не может прочитать значение; XSS всё ещё может отправлять аутентифицированные запросы. | Отправляется автоматически по правилам cookie; SameSite — лишь один уровень защиты CSRF. | Непрозрачную сессию можно отозвать на сервере; JWT в cookie требует отдельной политики отзыва. |
Рекомендуемая архитектура
- ✓Храните идентификаторы сессий в cookie
HttpOnly; Secure; SameSite=Lax. - ✓Не храните постоянные токены аутентификации в
localStorageилиsessionStorage.
Разделяйте формат токена, хранение и состояние сессии
JWT — формат токена, а localStorage и cookie — способы хранения и передачи данных браузером. JWT можно хранить любым из этих способов. Непрозрачный идентификатор сессии в cookie обычно указывает на состояние, хранящееся на сервере. «JWT или cookie» — не прямой выбор между равнозначными вариантами.
Что меняет каждый вариант
Браузер не добавляет значения localStorage автоматически к межсайтовым запросам, но XSS того же источника может прочитать bearer-токен или действовать через приложение. Cookie отправляются по правилам браузера; HttpOnly скрывает значение от JavaScript, но не мешает внедрённому коду пользоваться страницей с активной сессией. SameSite=Lax — один уровень защиты CSRF, а не полная гарантия: важны переходы верхнего уровня с безопасными методами и запросы same-site. Не меняйте состояние через GET и применяйте подходящую защиту CSRF, например проверенные токены и/или проверку Origin.
Отзыв зависит от состояния сервера и проверки токена, а не от места хранения. Серверную сессию можно сделать недействительной, удалив её запись. Самодостаточный JWT может приниматься до истечения срока без проверки отзыва; короткий срок уменьшает это окно, но не устраняет его.
Практический вариант
- ✓Для собственного веб-приложения выбирайте непрозрачную серверную сессию или Backend-for-Frontend (BFF), если это подходит архитектуре.
- ✓Задайте cookie сессии
Secure,HttpOnly, осознанныйSameSite,Path=/и, по возможности, безDomain; рассмотрите__Host-. - ✓Для запросов, меняющих состояние, используйте CSRF-токены и/или проверку Origin; никогда не меняйте состояние через
GET. - ✓Если JWT в браузере необходимы, задайте короткий срок, определите выход и отзыв, предотвращайте XSS. Cookie не заменяет проверки авторизации.