Безопасно ли хранить JWT в LocalStorage с реагировать?
В настоящее время я создаю одностраничное приложение с использованием actjs Я прочитал, что многие из причин не использовать localStorage из-за уязвимостей XSS. Поскольку React экранирует весь пользовательский ввод, будет ли теперь безопасно использовать localStorage?
15 ответов
В большинстве современных одностраничных приложений нам действительно нужно хранить токен где-то на стороне клиента (наиболее распространенный вариант использования - чтобы пользователь оставался в системе после обновления страницы).
Всего доступно 2 варианта: Веб-хранилище (хранилище сеансов, локальное хранилище) и файл cookie на стороне клиента. Оба варианта широко используются, но это не значит, что они очень безопасны.
Том Эбботт хорошо суммирует безопасность сеансов JWT и локального хранилища:
Веб-хранилище (localStorage / sessionStorage) доступно через JavaScript в том же домене. Это означает, что любой JavaScript, работающий на вашем сайте, будет иметь доступ к веб-хранилищу, и из-за этого может быть уязвим к атакам межсайтового скриптинга (XSS). Короче говоря, XSS - это тип уязвимости, когда злоумышленник может внедрить JavaScript, который будет работать на вашей странице. Базовые XSS-атаки пытаются внедрить JavaScript через ввод данных, где злоумышленник помещает
<script>alert('You are Hacked');</script>в форму, чтобы увидеть, если он запускается браузером и может быть просмотрен другими пользователями.
Чтобы предотвратить XSS, общим ответом является экранирование и кодирование всех ненадежных данных. React (в основном) делает это для вас! Вот отличная дискуссия о том, за что отвечает React за уязвимость XSS.
Но это не охватывает все возможные уязвимости! Другая потенциальная угроза - использование JavaScript, размещенного на CDN или за пределами инфраструктуры.
Вот снова Том
Современные веб-приложения включают сторонние библиотеки JavaScript для A/B-тестирования, анализа воронки / рынка и рекламы. Мы используем менеджеры пакетов, такие как Bower, чтобы импортировать чужой код в наши приложения.
Что если скомпрометирован только один из используемых вами сценариев? На страницу может быть встроен вредоносный JavaScript, и веб-хранилище будет взломано. Эти типы атак XSS могут получить все веб-хранилища, которые посещают ваш сайт, без их ведома. Вероятно, поэтому многие организации советуют не хранить ничего ценного или доверять какой-либо информации в веб-хранилище. Это включает в себя идентификаторы сеанса и токены.
Поэтому я пришел к выводу, что в качестве механизма хранения веб-хранилище не применяет никаких безопасных стандартов во время передачи. Любой, кто читает и использует веб-хранилище, должен проявить должную осмотрительность, чтобы всегда отправлять JWT по HTTPS, а не по HTTP.
В принципе, все в порядке, чтобы хранить ваш JWT в вашем локальном хранилище.
И я думаю, что это хороший способ. Если мы говорим о XSS, XSS с использованием CDN, это также потенциальный риск получения логина / пароля вашего клиента. Хранение данных в локальном хранилище предотвратит как минимум CSRF-атаки.
Вы должны осознавать и то и другое и выбирать, что хотите. Обе атаки - это не все, что вам нужно знать, просто помните: ВЫ БЕЗОПАСНЫ, КАК МЕНЬШЕ БЕЗОПАСНОЙ ТОЧКИ В ПРИЛОЖЕНИИ
Еще раз сохранение в порядке, быть уязвимым для XSS, CSRF,... не
Я знаю, что это старый вопрос, но согласно тому, что сказал @mikejones1477, современные интерфейсные библиотеки и фреймворки избегают текста, обеспечивая вам защиту от XSS. Причина, по которой куки-файлы не являются безопасным методом с использованием учетных данных, заключается в том, что куки-файлы не предотвращают CSRF, когда это делает localStorage (также помните, что куки-файлы доступны и с помощью javascript, поэтому XSS здесь не является большой проблемой), этот ответ возобновляется, почему.
Причина хранения токена аутентификации в локальном хранилище и ручного добавления его к каждому запросу защищает от CSRF - это ключевое слово: manual. Поскольку браузер не отправляет автоматически этот токен авторизации, если я захожу на evil.com и ему удается отправить POST http://example.com/delete-my-account, он не сможет отправить мой токен авторизации, поэтому запрос игнорируется.
Конечно, httpOnly - это святой Грааль, но вы не можете получить доступ через responsejs или какую-либо инфраструктуру js, у вас все еще есть уязвимость CSRF. Я бы порекомендовал localalstorage или, если вы хотите использовать куки, убедитесь, что вы реализуете какое-то решение вашей проблемы CSRF, как это делает django.
Что касается CDN, убедитесь, что вы не используете какие-то странные CDN, например, CDN, такие как google или bootstrap, поддерживаются сообществом и не содержат вредоносного кода, если вы не уверены, что вы можете свободно просматривать.
Меня беспокоят все ответы, которые предлагают не хранить в локальном хранилище, поскольку оно подвержено атаке XSS или вредоносной библиотеке. Некоторые из них даже приводят к многословным обсуждениям, хотя ответ довольно короткий/прямой, к которому я скоро вернусь.
Предложить это равносильно тому, чтобы сказать: «Не используйте сковороду для приготовления пищи, потому что, если вы напьетесь однажды ночью и решите пожарить, вы в конечном итоге сожжете себя и свой дом». Если jwt просочился из-за XSS-атаки или вредоносной библиотеки, то у владельца сайта есть более серьезная проблема: его сайт подвержен XSS-атакам или использует вредоносную библиотеку.
Ответ: если вы уверены, что на вашем сайте нет этих уязвимостей, сделайте это.
Ссылка: https://auth0.com/docs/security/data-security/token-storage#browser-local-storage-scenarios
Следует помнить одну вещь: являются ли JWT:
- Первая сторона (т.е. просто для доступа к вашим собственным серверным командам)
- Третье лицо (например, JWT для Google, Facebook, Twitter и т. д.)
Если JWT является собственным:
Тогда не имеет большого значения , храните ли вы JWT в локальном хранилище или в защищенном файле cookie (т.
Это связано с тем, что, если предположить, что XSS-атака успешна (т. е. злоумышленник смог вставить код Javascript через зависимость JS, которая теперь работает во всех браузерах посетителей), в любом случае «игра окончена»; все команды, которые должны были быть защищены «проверкой токена JWT», теперь могут быть выполнены злоумышленником, просто если скрипт, который они вставили во внешний JS, вызывает все необходимые конечные точки. Даже если они не могут прочитать сам токен JWT (из-за флага http-only файла cookie), это не имеет значения, потому что они могут просто отправить все необходимые команды, и браузер с радостью отправит токен JWT вместе с этими командами. .
Теперь, хотя ситуация с XSS-атакой, возможно, «игра окончена» в любом случае (будь то локальное хранилище или защищенный файл cookie), файлы cookie все еще немного лучше, потому что злоумышленник может выполнять атаки только тогда, когда у пользователя есть веб-сайт. открыть в своем браузере.
Это вызывает следующие «раздражения» для злоумышленника:
- «Моя XSS-инъекция сработала! Ладно, пора собирать личные данные о моем боссе и использовать их для шантажа. Черт возьми! Он входит в систему, только пока я здесь на работе. , и запустите его в течение трех минут, пока он там, вместо того, чтобы копаться в своих данных на платформе более постепенным / исследовательским способом».
- «Моя инъекция XSS сработала! Теперь я могу изменить код, чтобы вместо этого отправлять все переводы биткойнов мне! У меня нет какой-то конкретной цели, поэтому мне не нужно никого ждать. получить доступ к самому токену JWT - таким образом, я мог бы молча собрать их все, а затем разом опустошить все кошельки.С этими JWT, защищенными файлами cookie, я смогу перехватить только несколько десятков посетителей, прежде чем разработчики узнают и приостановят переводы ..."
- «Моя XSS-инъекция сработала! Это даст мне доступ даже к данным, которые могут видеть только администраторы. Хммм, к сожалению, мне приходится делать все через браузер пользователя. Я не уверен, что есть реальный способ загрузить эти данные». 3gb, используя это; я начинаю загрузку, но есть проблемы с памятью, и пользователь всегда закрывает сайт до того, как это будет сделано! Кроме того, я обеспокоен тем, что повторные передачи на стороне клиента такого размера могут быть обнаружены кем-то».
Если JWT является сторонним:
В этом случае это действительно зависит от того, что сторонние JWT позволяют делать держателю.
Если все, что они делают, это позволяют кому-то «получить доступ к базовой информации профиля» каждого пользователя, то это не так уж плохо, если злоумышленники могут получить к ней доступ; некоторые электронные письма могут просочиться, но злоумышленник, вероятно, все равно может получить это, перейдя на «страницу учетной записи» пользователя, где эти данные отображаются в пользовательском интерфейсе. (наличие токена JWT просто позволяет им избежать «неприятностей», перечисленных в предыдущем разделе)
Если вместо этого сторонние JWT позволяют вам делать более существенные вещи, например, иметь полный доступ к своим данным в облачном хранилище, отправлять сообщения на сторонние платформы, читать личные сообщения на сторонних платформах и т. д., тогда иметь доступ к JWT действительно значительно хуже, чем просто возможность «отправлять аутентифицированные команды».
Это связано с тем, что когда злоумышленник не может получить доступ к реальному JWT, ему приходится направлять все команды через ваш сторонний сервер. Это имеет следующие преимущества:
Ограниченные команды: поскольку все команды проходят через ваш сервер, злоумышленники могут выполнять только подмножество команд, для обработки которых был создан ваш сервер. Например, если ваш сервер когда-либо читает/записывает только из определенной папки в облачном хранилище пользователя, то у злоумышленника есть такое же ограничение.
Более простое обнаружение: поскольку все команды проходят через ваш сервер, вы можете заметить (через журналы, внезапный всплеск команд и т. д.), что кто-то разработал XSS-атаку. Это позволяет вам потенциально быстрее исправлять его. (если бы у них были сами JWT, они могли бы молча совершать звонки на сторонние платформы, вообще не связываясь с вашими серверами)
Дополнительные способы идентификации злоумышленника: поскольку команды проходят через ваш сервер, вы точно знаете, когда они выполняются и какой IP-адрес используется для их выполнения. В некоторых случаях это может помочь вам определить, кто совершает атаки. IP-адрес является наиболее очевидным способом, хотя, по общему признанию, большинство злоумышленников, способных к атакам XSS, будут достаточно осведомлены, чтобы использовать прокси.
Более продвинутый подход к идентификации может заключаться, скажем, в появлении специального всплывающего сообщения, уникального для каждого пользователя (или, по крайней мере, разбитого на сегменты), такого характера, что злоумышленник (когда он загружает веб-сайт со своего собственной учетной записи) увидит это сообщение и попытается запустить новую команду на его основе. Например, вы можете дать ссылку на «поддельный пост в блоге разработчика», в котором рассказывается о каком-то «новом API», который вы представляете, что позволяет пользователям получать доступ к еще большему количеству их личных данных; скрытая часть заключается в том, что URL-адрес этого «нового API» отличается для каждого пользователя, просматривающего сообщение в блоге., чтобы при попытке использования API (против жертвы) вы точно знали, кто это сделал. Конечно, это основано на идее, что у злоумышленника есть «настоящая учетная запись» на сайте вместе с жертвой, и он может соблазниться/обмануться таким подходом (например, это не сработает, если злоумышленник знает, что вы на него), но это пример того, что вы можете сделать, когда вы можете перехватывать все аутентифицированные команды.
Более гибкое управление: допустим, вы только что обнаружили, что кто-то развернул XSS-атаку на ваш сайт.
Если у злоумышленников есть сторонние JWT, ваши возможности ограничены: вам нужно глобально отключить/сбросить конфигурацию OAuth/JWT для всех сторонних платформ. Это вызывает серьезные сбои, когда вы пытаетесь выяснить источник атаки XSS, поскольку никто не может получить доступ к чему- либо с этих сторонних платформ. (включая ваш собственный сервер, поскольку токены JWT, которые он мог хранить, теперь недействительны)
Если вместо этого токены JWT защищены файлами cookie только для http, у вас есть больше возможностей: вы можете просто изменить свой сервер, чтобы «отфильтровать» любые операции чтения/записи, которые потенциально опасны. В некоторых случаях добавляется эта «фильтрация» — быстрый и простой процесс, позволяющий вашему сайту оставаться в режиме «только для чтения»/«ограниченный», не нарушая всего; в других случаях все может быть настолько сложно, что не стоит доверять коду фильтра из соображений безопасности. Дело в том, что у вас больше возможностей.
Например, возможно, вы не знаете наверняка , что кто-то развернул XSS-атаку, но подозреваете это. В этом случае вы можете не захотеть аннулировать токены JWT каждого пользователя (включая тех, которые ваш сервер использует в фоновом режиме) просто из-за подозрения на XSS-атаку (это зависит от вашего уровня подозрения). Вместо этого вы можете просто «сделать вещи доступными только для чтения на некоторое время», пока вы более внимательно изучаете проблему. Если выяснится, что все в порядке, вы можете просто щелкнуть переключателем и снова включить запись, при этом всем не придется снова входить в систему и тому подобное.
В любом случае, из-за этих четырех преимуществ я решил всегда хранить сторонние JWT в «защищенных файлах cookie», а не в локальном хранилище. Хотя в настоящее время сторонние JWT имеют очень ограниченные области (такие, что это не так уж важно, если они будут украдены), это хорошая перспектива сделать это на случай, если я захочу, чтобы мое приложение запрашивало доступ к более привилегированным функциям. в будущем (например, доступ к облачному хранилищу пользователя).
Примечание . Четыре вышеуказанных преимущества (для хранения сторонних JWT в защищенных файлах cookie) также могут частично применяться к сторонним JWT, если JWT используются в качестве аутентификации несколькими серверными службами, а также домены/IP-адреса этих других серверов. /услуги являются общедоступными. В этом случае они «эквивалентны сторонним платформам» в том смысле, что «куки-файлы только для http» ограничивают злоумышленника от отправки прямых команд на эти другие серверы, что дает часть преимуществ четырех пунктов выше. (это не совсем то же самое, поскольку вы, по крайней мере, контролируете эти другие серверы, поэтому вы можете активировать для них режим только для чтения и т. д., но, как правило, это будет больше работы, чем внесение этих изменений только в одном месте)
Localstorage разработан, чтобы быть доступным javascript, поэтому он не обеспечивает никакой защиты XSS. Как упоминалось в других ответах, существует множество возможных способов проведения XSS-атаки, от которых локальное хранилище по умолчанию не защищено.
Однако файлы cookie имеют флаги безопасности, которые защищают от атак XSS и CSRF. Флаг HttpOnly запрещает доступ к куки-файлам на стороне клиента, JavaScript-флаг позволяет браузеру передавать куки-файлы только через ssl, а флаг SameSite гарантирует, что куки-файлы отправляются только отправителю. Хотя я только что проверил и SameSite в настоящее время поддерживается только в Opera и Chrome, поэтому для защиты от CSRF лучше использовать другие стратегии. Например, отправка зашифрованного токена в другом файле cookie с некоторыми общедоступными данными пользователя.
Таким образом, файлы cookie являются более безопасным выбором для хранения аутентификационных данных.
Чтобы взглянуть на это, нужно принять во внимание уровень риска или вреда.
Вы создаете приложение без пользователей, POC/MVP? Вы стартап, которому нужно быстро выйти на рынок и протестировать свое приложение? Если да, я бы, вероятно, просто реализовал самое простое решение и сосредоточился на поиске продукта, подходящего для рынка. Используйте localStorage, так как его часто проще реализовать.
Вы создаете версию 2 приложения с большим количеством активных пользователей в день или приложение, от которого сильно зависят люди / компании. Будет ли взломать мало места для восстановления или нет? Если это так, я бы внимательно посмотрел на ваши зависимости и подумал о том, чтобы сохранить информацию токена в файле cookie только для http.
Использование как localStorage, так и хранилища файлов cookie/ сеансов имеет свои плюсы и минусы.
Как указано в первом ответе: если ваше приложение имеет XSS-уязвимость, ни одна из них не защитит вашего пользователя. Поскольку большинство современных приложений имеют дюжину или более различных зависимостей, становится все труднее гарантировать, что одна из зависимостей вашего приложения не будет уязвима для XSS.
Если в вашем приложении есть XSS-уязвимость, и хакер смог ее использовать, хакер сможет выполнять действия от имени вашего пользователя. Хакер может выполнять запросы GET/POST, получая токен из localStorage, или может выполнять запросы POST, если токен хранится в файле cookie только для http.
Единственным недостатком хранения вашего токена в локальном хранилище является то, что хакер сможет прочитать ваш токен.
Есть полезная статья , написанная доктором Филиппом Де Риком , которая дает представление об истинном влиянии уязвимостей, особенно XSS.
Эта статья открывает глаза!
Короче говоря, основной задачей разработчика должна быть защита веб-приложения от XSS, и ему не следует слишком беспокоиться о том, какой тип области хранения используется.
Доктор Филипп рекомендует следующие 3 шага:
Не беспокойтесь слишком о месте для хранения. Сохранение токена доступа в области localStorage сэкономит разработчику огромное количество времени для разработки следующих этапов приложения.
Проверьте свое приложение на наличие уязвимостей XSS. Выполните сквозную проверку кода и узнайте, как избежать XSS в рамках вашей структуры шаблонов.
Создайте механизм глубокой защиты от XSS. Узнайте, как еще больше заблокировать свое приложение. Например, с использованием политики безопасности контента (CSP) и песочницы HTML5.
Помните, что как только вы уязвимы для XSS, игра окончена!
Это небезопасно, если вы используете CDN:
На страницу может быть встроен вредоносный JavaScript, и веб-хранилище будет взломано. Эти типы атак XSS могут получить все веб-хранилища, которые посещают ваш сайт, без их ведома. Вероятно, поэтому многие организации советуют не хранить ничего ценного или доверять какой-либо информации в веб-хранилище. Это включает в себя идентификаторы сеанса и токены.
через шторм
Любой сценарий, который вам требуется извне, потенциально может быть скомпрометирован и может захватить любую JWTS из хранилища вашего клиента и отправить личные данные обратно на сервер злоумышленника.
Я опоздал к обсуждению, но с преимуществом более зрелых и современных протоколов аутентификации, таких как OpenID Connect.
TL;DR: Предпочтительный метод — хранить ваш токен JWT в памяти: не в файле cookie и не в локальном хранилище.
Подробности
Вы хотите отделить ответственность за аутентификацию пользователей от остальной работы, которую выполняет ваше приложение. Аутентификацию трудно сделать правильно, и горстка команд, которые тратят все свое время на размышления об этом, могут беспокоиться о деталях, которые вы и я никогда не поймем правильно.
Установите выделенного поставщика удостоверений для своего приложения и используйте протокол OpenID Connect для аутентификации с его помощью. Это может быть поставщик, такой как Google, Microsoft или Okta, или это может быть облегченный Identity Server, который объединяется с одной или несколькими из этих других служб.
Используйте поток кода авторизации , чтобы позволить пользователю пройти аутентификацию и получить маркер доступа к вашему приложению. Используйте уважаемую клиентскую библиотеку для обработки деталей OpenID Connect, чтобы библиотека уведомляла ваше приложение, когда у него есть действительный токен, когда новый действительный токен был получен с помощью обновления или когда токен не может быть обновлен (поэтому пользователю необходимо пройти повторную аутентификацию). Библиотека должна быть настроена (вероятно, по умолчанию), чтобы вообще не хранить токен.
Часто задаваемые вопросы
Что происходит, когда кто-то обновляет страницу? Я не хочу заставлять их снова входить в систему.
Когда приложение загружается впервые, оно всегда должно перенаправлять пользователя к вашему поставщику удостоверений. В зависимости от того, как этот поставщик удостоверений обрабатывает вещи, есть большая вероятность, что пользователю не придется входить в систему. Например, если вы федерируете с поставщиком удостоверений, таким как Google или Microsoft, пользователь может выбрать параметр, указывающий, что он находятся на доверенном устройстве и хотят, чтобы о них помнили. Если это так, им не нужно будет снова входить в систему в течение очень долгого времени, даже после того, как срок действия вашего токена аутентификации истечет. Это гораздо удобнее для ваших пользователей.
Опять же, если пользователь указал, что он находится на общем устройстве и не должен автоматически входить в систему в будущем, вы хотите принудительно войти в систему еще раз: вы не можете отличить того, кто обновил окно своего браузера, и того, кто снова открыл закрытый браузер. и перешел на страницу, сохраненную в истории браузера.
Разве поставщик удостоверений не использует файлы cookie, чтобы пользователь оставался в системе? А как насчет CSRF или XSS-атак?
Эти детали реализации относятся к поставщику удостоверений. Если они используют файлы cookie, их работа заключается в реализации мер по борьбе с CSRF. Они гораздо реже, чем вы, используют проблемные сторонние библиотеки или импортируют скомпрометированные внешние компоненты, потому что их приложение выполняет только одну задачу.
Разве я не должен вместо этого тратить свое время на борьбу с XSS-атаками? Разве это не «игра окончена», если кто-то внедрит код в мое приложение?
Если это предложение или/или, и у вас есть основания полагать, что ваше приложение имеет уязвимости XSS или Code Injection, то они определенно должны иметь приоритет. Но хорошая безопасность предполагает соблюдение лучших практик на нескольких уровнях для своего рода многоуровневой безопасности.
Кроме того, использование доверенной сторонней библиотеки для подключения к доверенным сторонним поставщикам безопасности должно сэкономить время, которое вы потратили бы на решение множества других проблем, связанных с безопасностью.
TLDR;
Оба работают, но использование cookie с httpOnly намного безопаснее , чем использование localStorage, поскольку любой вредоносный код javascript, введенный XSS, может прочитать localstorage.
Разве не приемлемы файлы cookie localStorage или httpOnly? Что касается скомпрометированной сторонней библиотеки, единственным известным мне решением, которое уменьшит / предотвратит кражу конфиденциальной информации, будет принудительная целостность субресурсов.
Подресурсная целостность (SRI) - это функция безопасности, которая позволяет браузерам проверять, что ресурсы, которые они выбирают (например, из CDN), доставляются без неожиданных манипуляций. Он работает, позволяя вам предоставить криптографический хеш, которому должен соответствовать извлекаемый ресурс.
Пока скомпрометированная сторонняя библиотека активна на вашем веб-сайте, кейлоггер может начать собирать такую информацию, как имя пользователя, пароль и все, что вы вводите на сайт.
Файл cookie httpOnly будет препятствовать доступу с другого компьютера, но ничего не изменит, чтобы хакер не смог манипулировать компьютером пользователя.
Я много лет работаю архитектором решений и вношу свой скромный вклад во всю эту дискуссию.
Хранение токенов безопасности, таких как JWT, на стороне клиента приемлемо, но все же посредственное решение, которое подвергает их межсайтовым атакам и взломам различной сложности.
Хорошей практикой обеспечения безопасности является введение промежуточных шагов, которые являются необычными и неожиданными для хакеров, особенно когда они не нацелены на конкретную систему.
Один из способов снизить уязвимость хранения и получения токенов на стороне клиента — применить к ним некоторые простые или сложные криптографические операции до и после процесса.
Более сложное решение — использовать отдельные общедоступные сертификаты клиента и сервера, которые работают вместе, чтобы обеспечить индивидуальную безопасность, выходящую за рамки стандартного шифрования, находящегося в процессе хранения и извлечения или использования этих токенов.
Большинство ответов на этот вопрос (включая принятый) говорят в пользу традиционных файлов cookie, а localStorage объявляется небезопасным способом хранения ваших конфиденциальных данных. Но это неправда. localStorage так же безопасен, как и традиционные файлы cookie. JavaScript также может получать доступ к файлам cookie, так как можно сказать, что файлы cookie безопасны, а localStorage - нет?
Если вы собираетесь разрешить ненадежные данные от пользователей и если вы позволите выполнить некоторый JavaScript на своем веб-сайте, вы в конечном итоге предоставите доступ злоумышленнику независимо от носителя, который вы используете для хранения вашей аутентификационной информации. JavaScript может перехватить файлы cookie сеанса или получить доступ к вашим данным localStorage, если вы разрешите это сделать.
Более того, CSRF обсуждался в других ответах, но здесь это совершенно не имеет значения. Защита CSRF служит другой (но бесполезной) цели. Если вы собираетесь создать надежную защиту от XSS в своем коде, вы можете доверять localStorage как безопасное место для ваших учетных данных для аутентификации.
В этом документе больше говорится о возможностях перехвата сеанса, и в основном он фокусируется на файлах cookie.
Итак, суть в том, что если вы позволяете хакеру выполнять JavaScript от вашего имени, ни один из способов не будет безопасным, будь то localStorage или cookie. Считайте localStorage шкафчиком. Если вы потеряете его ключи, вы не можете рассчитывать на его безопасность. Вы можете рассмотреть советы, обсуждаемые в других ответах, то есть не использовать JS из ненадежных CDN, чтобы защитить своих пользователей.
Хранить токен в localStorage безопасно, если вы его зашифруете. Ниже представлен сжатый фрагмент кода, показывающий один из многих способов сделать это.
import SimpleCrypto from 'simple-crypto-js';
const saveToken = (token = '') => {
const encryptInit = new SimpleCrypto('PRIVATE_KEY_STORED_IN_ENV_FILE');
const encryptedToken = encryptInit.encrypt(token);
localStorage.setItem('token', encryptedToken);
}
Затем перед использованием вашего токена расшифруйте его, используя PRIVATE_KEY_STORED_IN_ENV_FILE