Где хранить токен авторизации
Вопрос
Где на фронтенде хранить токены авторизации: в localStorage или в куках? Обоснуй.
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
`localStorage` читается любым JS: при XSS токен утечёт
Кука с `HttpOnly` недоступна из JS, `Secure` только по HTTPS
Куки уходят автоматически, поэтому нужна защита от CSRF: `SameSite` и/или CSRF-токен
Распространённая схема: короткий access-токен в памяти, refresh-токен в `HttpOnly` куке
`HttpOnly` не спасает от XSS полностью: скрипт может слать запросы от имени пользователя
Что могут спросить следом
- Как обновлять access-токен, если он только в памяти и вкладку перезагрузили?
- Что такое
SameSite=Laxи от чего он защищает? - Как синхронизировать выход из аккаунта между вкладками?
Разбор
Главный риск для токена это XSS. Всё, что лежит в localStorage или sessionStorage, любой скрипт на странице прочитает и отправит злоумышленнику, а потом токеном можно пользоваться откуда угодно. Кука с флагом HttpOnly из JS не читается, с Secure уходит только по HTTPS, поэтому украсть её через XSS нельзя. Но у кук своя проблема: браузер отправляет их сам, и появляется CSRF. От него защищает SameSite=Lax или Strict и, где нужно, CSRF-токен. На практике я бы выбрал схему: короткоживущий access-токен держать в памяти приложения, а refresh-токен в HttpOnly Secure SameSite куке, ограниченной путём эндпоинта обновления. При перезагрузке страницы приложение молча получает новый access-токен по куке. И важно понимать, что HttpOnly не делает XSS безобидным: внедрённый скрипт всё равно может делать запросы от имени пользователя, поэтому главная защита это не допускать XSS, плюс CSP.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.