Как защитить данные в LocalStorage от стороннего JavaScript?

Как защитить данные в LocalStorage от стороннего JavaScript?

• Контекст безопасности: клиентское хранилище и web security
• LocalStorage не использует шифрование и доступен любому скрипту, выполняющемуся в пределах того же домена.
• Базовый уровень защиты обеспечивает изоляция по origin, который определяется протоколом, доменом и портом.
• Наиболее критичная угроза для данных в LocalStorage — XSS, позволяющая внедрить сторонний JavaScript.
• Основные меры защиты:
• Настроить Content Security Policy (CSP), чтобы блокировать запуск неавторизованных скриптов.
• Тщательно очищать и экранировать пользовательский ввод, предотвращая инъекции.
• Сократить применение inline-скриптов и зависимостей от сторонних библиотек.
• Шифровать данные в LocalStorage на стороне клиента, например с помощью AES, понимая, что такая мера ограничена и зависит от защищённости ключа.
• Рассмотреть другие варианты: хранить чувствительные данные на сервере либо использовать HttpOnly куки.
• Вывод: безопасность LocalStorage прежде всего строится на предотвращении внедрения стороннего JS через XSS, а не на защите самого хранилища.

Надёжная защита возможна только при комплексном подходе к безопасности фронтенда: без ограничения запуска JavaScript напрямую закрыть LocalStorage от сторонних скриптов практически невозможно.

Подробный ответ

Основной ответ

LocalStorage — браузерное хранилище на стороне клиента, которое по своей архитектуре доступно любому JavaScript-коду в пределах одного домена (origin). Поэтому через сам LocalStorage нельзя изолировать данные от сторонних скриптов, работающих на том же домене: политика безопасности браузера (SOP) не предусматривает разграничение доступа между скриптами одного origin. Защищать данные от стороннего JS нужно комплексом дополнительных мер.

Ключевые моменты

• Изоляция по домену: встроенного механизма, который ограничивал бы доступ к LocalStorage для отдельных скриптов внутри одного origin, нет. Все скрипты этого origin получают одинаковые права.
• Шифрование данных: дополнительный уровень защиты можно получить, сохраняя в LocalStorage только зашифрованные данные. Шифрование и расшифровка выполняются приложением, а ключ не размещается в LocalStorage — например, он может находиться в session или вводиться пользователем. Это уменьшает последствия утечки даже в ситуации, когда сторонний скрипт прочитает содержимое LocalStorage.
• Content Security Policy (CSP) и Subresource Integrity (SRI): правильно настроенная CSP ограничивает загрузку и выполнение сторонних скриптов, снижая вероятность запуска вредоносного кода с доступом к LocalStorage. SRI, в свою очередь, подтверждает целостность загружаемых ресурсов.
• Разделение логики: можно применять iframe с другим origin или современный API, например, IndexedDB с контролем доступа. Чувствительные данные также следует хранить на сервере и передавать по защищённым каналам.
• Отказ от LocalStorage для чувствительных данных: критически важную информацию рекомендуется размещать в более защищённых механизмах — например, в HttpOnly cookie, недоступных JavaScript, либо в памяти приложения, чтобы снизить вероятность утечки.

Практический контекст

На практике данные перед записью в LocalStorage нередко шифруют с использованием Crypto API браузера, например AES-GCM, а ключами управляют на стороне приложения. CSP-заголовки, заданные на уровне сервера, запрещают выполнение неподписанных скриптов и помогают противодействовать XSS-атакам, которые часто открывают стороннему коду доступ к LocalStorage. Если данные особенно чувствительны, предпочтительнее хранить их на сервере и получать через авторизованные запросы.