Почему доступ браузерных расширений к localStorage является уязвимостью

Что проверяют

Понимаете ли вы, что localStorage это просто хранилище, доступное любому скрипту в источнике, и что механизмов защиты у него нет вовсе. Формально вопрос про расширения, на деле проверяют, где вы храните токен сессии.

Как отвечать

Опишите, как устроен доступ. localStorage привязан к источнику и читается синхронно из любого JavaScript, который в этом источнике выполняется. Контент-скрипт расширения выполняется именно там: у него изолированный набор переменных, но DOM и хранилище общие со страницей. Расширению достаточно разрешения на хост, дальше localStorage.getItem отдаёт токен открытым текстом, и согласия страницы никто не спрашивает.

Дальше важное: страница от этого не защищается. Политика безопасности контента ограничивает скрипты самой страницы, но не контент-скрипты расширения. Шифрование на клиенте тоже не помогает, ключ лежит рядом, в том же коде или в том же хранилище.

Правильный вывод: localStorage годится для настроек интерфейса, черновиков формы и выбранной темы, а сессию держат в cookie с флагами HttpOnly, Secure, SameSite. Такую cookie не прочитает ни скрипт страницы, ни контент-скрипт. Плюс короткое время жизни токена доступа и обновление по отдельному механизму, чтобы украденное быстро протухало.

Где спотыкаются

Считают расширения уникальной угрозой. Тот же токен вытащит любая XSS-дыра и любая скомпрометированная сторонняя библиотека в бандле. Расширение это самый наглядный пример, а корень один: хранилище открыто скриптам источника.

Второе: называют cookie безопасной саму по себе. Без HttpOnly она читается через document.cookie ровно так же, а без SameSite к краже добавляется ещё и CSRF.

Третье: путают localStorage и sessionStorage. Второй живёт до закрытия вкладки, но защищённее не становится: из той же вкладки он читается теми же способами и тем же расширением.