Типизация Web Crypto API и безопасного хранения JWT в IndexedDB через дедуплицированные...
Типизация Web Crypto API и безопасного хранения JWT в IndexedDB через дедуплицированные Streams и CryptoKey в Service Worker Большинство разработчиков доверяют JWT localStorage, пока не случается XSS. Но уровень угроз растет, и даже продуманное хранение токенов требует системной защиты — от шифрования до изоляции ключа. В production-проектах с высокими требованиями безопасности IndexedDB в связке с Web Crypto API и Service Worker — это не перебор, а инженерный минимум. Почему подход на CryptoKey и Service Worker работает Ключ шифрования создается в SW с флагом extractable: false. Это означает, что его нельзя экспортировать через crypto.subtle.exportKey — даже при полном доступе к SW контексту. Сам JWT хранится в IndexedDB в зашифрованном виде с уникальным IV на каждую запись. Злоумышленник, получивший данные из БД через основной поток, видит только бинарный шум. Дедупликация операций через Streams При параллельных запросах на дешифровку одного токена криптооперации дублируются, что нагружает CPU. Решение — хранить в Map Promise на каждый ключ данных. Если промис уже существует, возвращаем его, а не создаем новый. Это снижает нагрузку и гарантирует консистентность результата. AbortController помогает отменять зависшие операции при истечении времени. Пример записи и чтения в SW const key = await crypto.subtle.generateKey( { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt'] ); const iv = crypto.getRandomValues(new Uint8Array(12)); const encrypted = await crypto.subtle.encrypt( { name: 'AES-GCM', iv }, key, new TextEncoder().encode(jwt) ); await db.put('jwt', { id: 'token', iv, data: encrypted }); Для чтения: извлекаем запись, дешифруем в SW с дедупликацией через Map промисов. Если запрос на дешифровку уже выполняется, не создаем новый, а возвращаем существующий Promise. Типичная ошибка и trade-off Ошибка: считать, что SW защищает от CSRF. Это не так — нужны SameSite куки и строгая CSP. Еще одна проблема — отладка: SW живет изолированно, синхронизация состояния между ним и UI через postMessage или BroadcastChannel усложняет трассировку багов. Для high-security сценариев (финтех, медицина) это оправданно, но для обычных CRUD приложений избыточно. Вывод: Хранение JWT в IndexedDB с шифрованием через CryptoKey в Service Worker снижает XSS-риски до минимума, но требует дополнительной защиты от CSRF и осознанной сложности отладки.