Browser threat model неудобен тем, что frontend одновременно является и пользовательским интерфейсом, и недоверенной средой исполнения. Здесь нельзя просто 'положиться на backend': XSS, CSRF, token leakage, third-party scripts и supply-chain риски живут прямо в клиентской поверхности.
Глава ценна тем, что помогает говорить о frontend security как об архитектуре доверенных границ. Она показывает, почему CSP, cookie strategy, storage choices, sandboxing и политика подключения внешних скриптов должны приниматься так же осознанно, как API security или доступ к данным на сервере.
Для design review это особенно полезный материал, потому что он заставляет смотреть на браузер не как на harmless view-layer, а как на публичный runtime с постоянным давлением со стороны attacker-модели и продуктовых компромиссов.
Практическая польза главы
Практика проектирования
Переводите знания о browser threat model, доверенных границах и защите frontend-поверхности в конкретные решения по composition, владению (ownership) и runtime-поведению клиентской системы.
Качество решений
Оценивайте архитектуру по измеримым эффектам: скорость delivery, стабильность UI, наблюдаемость, цена изменений и эксплуатационные риски.
Аргументация на интервью
Стройте ответ как цепочку problem -> constraints -> architecture -> компромиссы (trade-offs) -> migration path, с явной аргументацией frontend-выбора.
Формулировка компромиссов
Фиксируйте компромиссы вокруг browser threat model, доверенных границах и защите frontend-поверхности: масштаб команды, технический долг, performance budget и долгосрочная поддержка.
Контекст
OWASP Top 10 in the context of System Design
Browser threat model - это не отдельный мир, а клиентское продолжение тех же security assumptions и defaults.
Frontend живет в недоверенной среде исполнения. Пользовательский браузер, сторонние расширения, injected scripts и произвольный network environment означают, что клиент нельзя считать безопасным местом для логики доверия, хранения секретов или неконтролируемого HTML.
Поэтому security для frontend начинается не с чеклиста уязвимостей, а с вопроса: какие границы доверия реально существуют в браузере.
Главные классы угроз
XSS и script injection
Самый болезненный класс угроз для frontend: user-controlled HTML, unsafe markdown rendering, third-party widgets и DOM-based sinks быстро превращают UI в точку захвата токенов и пользовательских действий.
CSRF, session fixation и browser trust assumptions
Даже если auth реализован сервером, frontend обязан понимать, как работают cookies, same-site policy, redirect flows и anti-replay assumptions в браузере.
Token storage и client secrets illusion
Любые long-lived tokens в browser storage должны оцениваться как потенциально доступные злоумышленнику. Frontend не должен считать localStorage или embedded config безопасным сейфом.
Supply chain и third-party scripts
Analytics, chat widgets, A/B tooling, CDN-hosted libraries и browser extensions расширяют attack surface. Их нужно проектировать как часть threat model, а не как маркетинговую интеграцию.
Слои защиты
CSP и ограничение источников скриптов
CSP не решает все проблемы, но резко сокращает стоимость случайного XSS. Особенно важны nonce/hash strategy, запрет inline script и контроль third-party domains.
Безопасные auth boundaries
Session cookies, PKCE, short-lived tokens, refresh rotation и backend-for-frontend часто безопаснее, чем жирные bearer tokens, разбросанные по клиентскому коду.
Escaping и typed rendering surfaces
Каждый путь, который рендерит HTML, markdown, template fragments или dangerously-set markup, должен быть отдельной reviewed boundary с sanitize policy.
Dependency hygiene и provenance
Lockfiles, dependency review, artifact integrity и ограничение числа пакетов нужны фронтенду не меньше backend-сервисам.
Security review вопросы
- Какие данные мы считаем trusted в браузере и на чем основано это доверие.
- Можно ли выполнить произвольный скрипт через content path, markdown, WYSIWYG или third-party snippet.
- Какие client-side tokens или session artifacts дают слишком большой blast radius при компрометации.
- Как быстро мы можем отключить небезопасную внешнюю интеграцию или флаг без полной перекатки продукта.
Ошибочная интуиция
Считать frontend “тонким view layer” и поэтому не проводить отдельный threat modeling для browser-side flows. Именно из-за этого поздно замечают XSS sinks, слабые third-party integrations и опасные решения по token storage.
Browser security зрелого frontend-продукта держится на безопасных defaults: controlled rendering surfaces, minimal token exposure, strict script policy и возможности быстро выключить небезопасную интеграцию.
Связанные главы
- OWASP Top 10 in the context of System Design - дает общую карту рисков, которые на frontend превращаются в browser-specific attack paths.
- API Security Patterns - добавляет backend boundary: authn/authz, anti-replay, schema validation и abuse prevention.
- Identification, Authentication and Authorization (AuthN/AuthZ) - важна для понимания session model, cookie strategy и token lifecycle на клиенте.
- Supply Chain Security - расширяет тему dependency hygiene, provenance и доверия к внешним пакетам.
- Data layer во фронтенде: REST, GraphQL, BFF и orchestration - показывает, как более безопасный data boundary может уменьшить exposure client tokens и raw backend complexity.