Браузерное хранилище, предоставляемое через localForage, создаёт
удобный слой абстракции над IndexedDB, WebSQL и localStorage. Несмотря
на гибкость и простоту API, модель хранения остаётся строго клиентской и
потенциально уязвимой по своей природе. Это определяет ключевое
ограничение: не все данные допустимо сохранять в таком хранилище, даже
если технически это возможно.
Любое клиентское хранилище следует рассматривать как
ненадёжную среду с точки зрения конфиденциальности, где
данные могут быть прочитаны пользователем, расширениями браузера или
скомпрометированным окружением.
Почему
клиентское хранилище не является защищённым
localForage работает поверх механизмов браузера, которые не
предоставляют криптографической изоляции данных по умолчанию. Это
означает:
- данные доступны через инструменты разработчика браузера;
- расширения могут получить доступ к хранилищу;
- вредоносный скрипт, внедрённый в контекст страницы, может извлечь
содержимое;
- резервные копии профиля браузера содержат сохранённые значения;
- синхронизация профиля (если включена) может дублировать данные на
сторонние серверы.
Даже при использовании IndexedDB уровень защиты ограничен политиками
браузера, а не криптографией.
Категории данных,
которые нельзя хранить
Аутентификационные данные
Критически важно исключить хранение:
- паролей в открытом виде;
- PIN-кодов и одноразовых кодов (OTP);
- секретных ключей API с полными правами;
- токенов доступа без ограничений и сроков действия.
Даже токены с ограниченными правами требуют осторожности. В случае
компрометации браузерного профиля они становятся эквивалентом полного
доступа к аккаунту.
Особенно опасны долгоживущие refresh-токены, так как их компрометация
позволяет поддерживать доступ длительное время без повторной
аутентификации.
Персональные
идентификаторы высокой чувствительности
Не следует сохранять:
- паспортные данные;
- номера банковских карт;
- CVV-коды;
- данные банковских счетов;
- налоговые идентификаторы;
- биометрические данные (в любом виде, включая хеши при слабой модели
угроз).
Такие данные подпадают под повышенные требования безопасности (GDPR,
PCI DSS и аналогичные стандарты), которые предполагают серверную
изоляцию и шифрование на уровне инфраструктуры.
Медицинская и юридическая
информация
localForage не предназначен для хранения:
- медицинских диагнозов;
- результатов анализов;
- истории лечения;
- юридических документов и конфиденциальных материалов дел.
Даже при локальном характере приложения такие данные требуют
контролируемых сред хранения с шифрованием и аудитом доступа.
Приватные пользовательские
данные
К этой категории относятся:
- личные сообщения и переписка;
- приватные файлы;
- фотографии и видео с чувствительным содержанием;
- геолокация в реальном времени;
- история действий, которая может раскрывать поведение
пользователя.
Даже если приложение работает офлайн, хранение подобных данных в
localForage создаёт риск их утечки через браузер или устройство.
Почему
шифрование в браузере не решает проблему полностью
Попытка компенсировать ограничения через клиентское шифрование
кажется очевидным решением, однако имеет ограничения:
- ключи шифрования часто хранятся рядом с данными;
- JavaScript-реализация криптографии уязвима к XSS;
- отсутствие аппаратного доверенного хранилища снижает
устойчивость;
- невозможность безопасного управления ключами между сессиями.
Даже при использовании Web Crypto API модель угроз остаётся
клиентской, а значит компрометация браузера приводит к компрометации
данных.
Типичные ошибочные
сценарии использования
Кэширование токена
авторизации «для удобства»
Частая ошибка — сохранение access token в localForage для ускорения
логина. Даже если токен короткоживущий, его перехват может привести
к:
- доступу к пользовательским данным;
- выполнению действий от имени пользователя;
- обходу серверной аутентификации.
Корректный подход предполагает использование HTTP-only cookies или
временных in-memory хранилищ.
Хранение профиля
пользователя целиком
Иногда в localForage сохраняют полный объект пользователя:
- email;
- телефон;
- адрес;
- настройки аккаунта;
- внутренние идентификаторы.
Проблема заключается в том, что такие данные часто становятся точкой
восстановления личности и используются в атаках социальной
инженерии.
Сохранение API-ключей
сторонних сервисов
Хранение ключей, даже ограниченных, в клиентском хранилище приводит
к:
- их извлечению через DevTools;
- использованию третьими лицами;
- превышению квот и финансовым потерям;
- подмене запросов.
API-ключи должны храниться исключительно на сервере.
Модель угроз для localForage
При проектировании системы важно учитывать следующие угрозы:
- пользователь с доступом к своему устройству;
- расширения браузера с доступом к DOM и storage;
- XSS-атаки в рамках приложения;
- вредоносные скрипты сторонних библиотек;
- физический доступ к профилю браузера;
- синхронизация данных между устройствами.
localForage не защищает от этих сценариев, так как его задача —
удобное хранение, а не безопасность.
Корректные
альтернативы для чувствительных данных
Чувствительные данные должны храниться:
- на сервере с контролем доступа;
- в зашифрованных базах данных;
- в системных хранилищах ОС (Keychain, Credential Manager);
- через HTTP-only secure cookies для сессионных данных.
localForage при этом остаётся инструментом для:
- кэширования публичных данных;
- хранения настроек интерфейса;
- офлайн-данных без критической ценности;
- временных состояний приложения.
Разделение данных
по уровню чувствительности
Практически полезная модель классификации:
- Низкая чувствительность: UI-настройки, темы,
фильтры, кеш.
- Средняя чувствительность: временные
пользовательские предпочтения, неидентифицирующие данные.
- Высокая чувствительность: персональные, финансовые,
медицинские данные — запрещены для хранения в клиентском хранилище.
localForage допустим только для первых двух уровней при условии
отсутствия критической утечки при компрометации.
Ошибки архитектурного
мышления
Наиболее распространённая проблема — восприятие localForage как
аналога серверной базы данных. Это приводит к:
- попытке хранить «всё локально»;
- игнорированию модели угроз браузера;
- переоценке безопасности клиентского окружения;
- смешиванию кеша и персистентного хранилища безопасности.
Браузерное хранилище всегда должно рассматриваться как
кеш-слой, а не как защищённое хранилище данных.