Модель угроз браузера неудобна тем, что фронтенд одновременно является пользовательским интерфейсом и недоверенной средой выполнения. Здесь нельзя просто положиться на серверную сторону: XSS, CSRF, утечки токенов, сторонние скрипты и риски цепочки поставки живут прямо в клиентской поверхности.
Глава помогает говорить о безопасности фронтенда как об архитектуре границ доверия. Она показывает, почему CSP, стратегия cookie, выбор места хранения токенов, изоляция стороннего кода и политика внешних скриптов должны приниматься так же осознанно, как защита API или доступ к данным на сервере.
Для ревью архитектуры материал полезен тем, что заставляет смотреть на браузер не как на тонкий слой отображения, а как на публичную среду выполнения под постоянным давлением со стороны атакующей модели и продуктовых компромиссов.
Практическая польза главы
Практика проектирования
Проектируйте браузерные границы явно: пользовательский ввод, поверхности рендеринга, хранение токенов, API/BFF и сторонний код.
Качество решений
Оценивайте решения по радиусу поражения: что сможет сделать злоумышленник при XSS, утечке токена или компрометации внешнего скрипта.
Аргументация на интервью
Стройте ответ как цепочку: недоверенная среда, актив, путь атаки, мера защиты и остаточный риск.
Формулировка компромиссов
Фиксируйте цену выбора: удобство клиента, безопасность сессии, ограничения CSP, стоимость интеграций и скорость релиза.
Контекст
OWASP Top 10 в контексте системного дизайна
Модель угроз браузера продолжает те же архитектурные вопросы: где проходит граница доверия, кто принимает решение и что нельзя отдавать клиенту.
Фронтенд живёт в , которой вы не управляете: чужой браузер, его расширения, внедрённые скрипты и любые сетевые условия. Поэтому клиент нельзя считать безопасным местом для логики доверия, хранения секретов или неконтролируемого HTML — всё, что туда попало, в худшем случае уже у злоумышленника.
Поэтому начинается не с чек-листа уязвимостей, а с вопроса: какие границы доверия реально существуют в браузере.
Дальше , пользовательский ввод, , , CSP, сторонние скрипты, хранение токенов, , поверхность атаки и собраны в одну архитектурную рамку, а не в разрозненный список уязвимостей.
Архитектурная карта модели угроз браузера
Схема показывает, где в браузере появляются границы доверия: пользовательский ввод, клиентский код, сессия, API/BFF и сторонний код требуют разных защитных решений.
Где заканчивается доверие к клиенту
Браузер нельзя считать доверенным контуром: каждая граница должна явно ограничивать, что клиент может хранить, выполнить и отправить дальше.
Среда
Недоверенный браузер
Пользователь, расширения, сеть и локальное хранилище находятся вне полного контроля команды.
Код
Код приложения
Клиентская логика должна считать входные данные недоверенными и не хранить секреты.
Сессия
Хранилище и сессия
Cookie, токены и локальные данные определяют радиус поражения при XSS или утечке.
Граница
API или BFF
Серверная граница подтверждает действие, права доступа и форму запроса, а не верит UI.
Расширение
Сторонний код
Виджеты, аналитика и пакеты получают ровно столько доступа, сколько разрешено политиками.
Когда смотреть сюда
- Появляется новый внешний скрипт, виджет или пакет.
- Нужно выбрать место хранения токена или сессионного состояния.
- Команда спорит, какие проверки должны жить на клиенте, а какие на сервере.
Архитектурный смысл
Карта доверия помогает не путать удобство UI с безопасной границей: браузер показывает сценарий, но сервер всё равно принимает окончательное решение.
Главные классы угроз в браузере
XSS и внедрение скриптов
Самый болезненный класс угроз для браузера: пользовательский HTML, небезопасный , сторонние виджеты и быстро превращают интерфейс в точку захвата токенов и пользовательских действий.
CSRF, фиксация сессии и допущения доверия в браузере
Даже если вход реализован сервером, фронтенд обязан понимать, как работают cookie, , , и защита от повторного воспроизведения запроса.
Хранение токенов и иллюзия клиентских секретов
Любой в стоит считать уже утёкшим: один XSS — и он у злоумышленника. localStorage и встроенная конфигурация выглядят как сейф, но защиты от чтения чужим скриптом у них нет.
Цепочка поставки фронтенда и сторонний код
Каждый внешний скрипт выполняется с теми же правами, что и ваш код. Аналитика, чат-виджеты, A/B-инструменты, библиотеки из и расширения браузера расширяют ровно настолько, насколько вы им доверяете. Это часть модели угроз, а не безобидная маркетинговая интеграция.
Слои защиты
CSP и ограничение источников скриптов
не решает все проблемы, но резко сокращает цену случайного XSS. Особенно важны , , запрет и контроль доменов сторонних поставщиков.
Безопасные границы аутентификации
, , короткоживущие учётные данные, ротация токена обновления и часто безопаснее, чем мощные bearer-токены, разбросанные по клиентскому коду.
Очистка данных и безопасные поверхности рендеринга
Каждый путь, который рендерит HTML, Markdown, шаблонные фрагменты или опасную HTML-вставку, — это отдельная граница, которую кто-то должен проверить со своей . Пропущенная граница молчит до тех пор, пока в неё не прилетит чужой скрипт.
Гигиена зависимостей и происхождение артефактов
, , и ограничение числа пакетов нужны фронтенду не меньше, чем серверным сервисам.
Вопросы для ревью безопасности
- Какие данные мы считаем доверенными в браузере и на чём основано это доверие.
- Можно ли выполнить произвольный скрипт через контент, Markdown, или сторонний фрагмент.
- Какие клиентские токены или сессионные артефакты дают слишком большой при компрометации.
- Как быстро мы можем отключить небезопасную внешнюю интеграцию или фича-флаг без полной перекатки продукта.
Ошибочная интуиция
Считать фронтенд тонким слоем отображения и поэтому не проводить отдельное для браузерных сценариев. Именно из-за этого поздно замечают XSS-приёмники, слабые сторонние интеграции и опасные решения по хранению токенов.
Признак зрелости
В зрелом фронтенд-продукте безопасность держится не на героизме ревьюера, а на настройках по умолчанию: контролируемые поверхности рендеринга, минимальный доступ токенов, строгая политика скриптов и возможность выключить небезопасную интеграцию за минуты, а не за релиз.
Связанные главы
- OWASP Top 10 в контексте системного дизайна - даёт общую карту рисков, которые во фронтенде превращаются в браузерные пути атаки.
- API Security Patterns - добавляет серверную границу: аутентификацию, авторизацию, защиту от повторного воспроизведения запроса, проверку схемы и защиту от злоупотреблений.
- Идентификация, аутентификация и авторизация (AuthN/AuthZ) - важна для понимания модели сессии, стратегии cookie и жизненного цикла токенов на клиенте.
- Безопасность цепочки поставки ПО - расширяет тему гигиены зависимостей, происхождения артефактов и доверия к внешним пакетам.
- Слой данных во фронтенде: REST, GraphQL, бэкенд для фронтенда (BFF) и оркестрация - показывает, как безопасная граница данных снижает риск утечки клиентских токенов и скрывает внутреннюю сложность серверной стороны.