Безопасность: что никогда не следует хранить в хранилище

localStorage и sessionStorage сохраняют данные на диске без шифрования, в профиле пользователя. Любой процесс с доступом к файловой системе — включая вредоносные программы, средства резервного копирования или другого вошедшего в систему пользователя — может прочитать каждое сохранённое значение, не обращаясь к браузеру.

Все скрипты, работающие в одном источнике, используют одно и то же хранилище. Успешная XSS-атака, скомпрометированный сторонний SDK или вредоносное расширение браузера могут вызвать localStorage.getItem и украсть все сохранённые значения. Изоляции между скриптами нет.

Не помещайте токены сеанса, токены JWT, токены обновления или ключи API в localStorage. Если злоумышленник внедрит всего одну строку JavaScript, токен немедленно утечёт. Используйте файлы cookie с атрибутами httpOnly и SameSite, а также с включённой безопасной передачей, чтобы токен никогда не был доступен из JavaScript.

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

PCI-DSS запрещает хранить номера карт, коды CVV, данные магнитной полосы или сроки действия в клиентском хранилище. Вместо этого используйте токенизированного платёжного провайдера (Stripe, Braintree, Adyen), который возвращает краткоживущий токен, привязанный к вашему источнику.

Государственные удостоверения личности, полные даты рождения, домашние адреса и медицинские данные привлекают внимание регуляторов (GDPR, HIPAA) и злоумышленников. Храните только то, что требуется для текущего сеанса, повторно запрашивайте эти данные при необходимости, а источником достоверных данных пусть остаётся сервер.

Уязвимость XSS, из-за которой раскрывается document.cookie, уже опасна. Та же уязвимость на странице, где токены хранятся в localStorage, передаёт злоумышленнику сразу все сохранённые значения. Считайте localStorage областью, где «если скомпрометирован один скрипт, скомпрометировано всё».

Шифрование значений ключом, который также находится в JavaScript, не обеспечивает реальной защиты — злоумышленник, способный прочитать зашифрованные данные, сможет прочитать и ключ. Настоящие секреты должны оставаться на сервере и выдаваться заново, а не сохраняться на стороне клиента.

Настройки интерфейса (тема, свёрнутая боковая панель, язык), несекретные флаги функций, содержимое черновиков форм и временное состояние пошаговых форм вполне можно хранить. Пользователь всё равно может их увидеть, а их утечка не позволяет захватить учётную запись.

Передавайте данные для аутентификации через Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. Флаг HttpOnly делает cookie недоступным JavaScript и тем самым нейтрализует большинство XSS-нагрузок для кражи токенов, даже если на странице есть другие уязвимости.

Если необходимо кэшировать потенциально чувствительные данные, жёстко ограничьте область их действия (короткий TTL, очищайте данные при выходе из системы, удаляйте их при закрытии вкладки через sessionStorage), применяйте строгую политику безопасности содержимого для блокировки внедрённых скриптов и проверяйте каждый сторонний скрипт, работающий на страницах после аутентификации.

Веб-хранилище хранит данные в открытом виде, доступно для чтения скриптам и является общим для источника. Никогда не помещайте туда токены аутентификации, пароли, платёжные данные или персональную информацию, регулируемую законом. Храните секреты в cookie с флагом httpOnly, а localStorage оставляйте для безвредного состояния интерфейса, которое пользователь и так мог бы увидеть.