Безопасность frontend-приложений¶

Требования этого документа применяются к безопасности frontend-приложений профилей CSR, SSR, SSG и edge по frontend/rendering-profiles.md. Требование, явно называющее browser или DOM, применяется только к browser-части. Серверная аутентификация и авторизация регулируются документами security/authentication.md и security/authorization.md. Уровни обязательности определены в корневом README.md.

FE-SEC-002. Content Security Policy¶

Уровень: MUST

Применяется к: каждой поставляемой странице приложения

Приложение должно поставляться со строгой Content Security Policy (CSP), ограничивающей источники скриптов, стилей, изображений, соединений и фреймов. Inline-скрипты и inline-стили должны устраняться или защищаться nonce либо hash.

Переход от Content-Security-Policy-Report-Only к enforcing должен быть отдельным управляемым изменением. Политика не должна содержать небезопасные директивы вроде unsafe-inline или unsafe-eval без обоснованной необходимости и компенсирующих мер.

Обоснование¶

CSP ограничивает исполнение внедрённого и стороннего кода и снижает последствия XSS и компрометации зависимости.

Проверка¶

security-тест нарушения CSP тестовым вектором;
review заголовков CSP и отчётов о нарушениях;
проверка отсутствия unsafe-inline и unsafe-eval без обоснования.

Исключения¶

Использование unsafe-eval требует ADR с моделью угроз и компенсирующими мерами.

FE-SEC-003. Предотвращение XSS¶

Уровень: MUST

Применяется к: отображению данных в DOM

Приложение должно использовать средства framework для автоматического экранирования вывода. Рендеринг пользовательского или внешнего HTML, использование небезопасных конструкций вроде v-html, dangerouslySetInnerHTML или innerHTML допускается только после санитизации проверенной библиотекой по явно определённому allowlist.

Приложение не должно формировать URL для активных контекстов из непроверенного ввода без проверки схемы.

Обоснование¶

XSS позволяет выполнить код в контексте приложения и сессии пользователя.

Проверка¶

security-тест инъекции разметки в каждое место вывода;
статический поиск небезопасных конструкций рендеринга;
review allowlist санитизации.

Исключения¶

Не допускаются для вывода непроверенного ввода без экранирования или санитизации.

FE-SEC-004. Хранение токенов и сессии¶

Уровень: MUST

Применяется к: хранению учётных данных в браузере

Приложение не должно сохранять access token или refresh token в localStorage или другом доступном JavaScript долговременном хранилище. Предпочтительной является server-side session с cookie, имеющей Secure, HttpOnly и подходящий контексту SameSite, в согласии с SEC-AUTHN-009. Передача сессии и токенов должна выполняться по TLS по SEC-TLS-001, а атрибут Secure уже обеспечивает использование cookie только по защищённому соединению.

В публичном клиенте без server-side session access token MAY храниться только в памяти процесса страницы с минимальным сроком действия. Refresh token не должен помещаться в доступное JavaScript долговременное хранилище.

Обоснование¶

Token предъявителя в доступном JavaScript-хранилище похищается XSS и расширениями браузера.

Проверка¶

security review способа хранения токенов;
тест доступа к хранилищу из скрипта;
проверка атрибутов cookie.

Исключения¶

Иной способ хранения token в доступном JavaScript хранилище требует утверждённого ADR с моделью угроз по SEC-AUTHN-009.

FE-SEC-005. Авторизация выполняется на backend¶

Уровень: MUST

Применяется к: каждой защищённой операции

Frontend может скрывать недоступное действие или данные, но эта проверка не заменяет авторизацию на backend. Решение о доступе должно приниматься сервером, владеющим операцией или данными, по SEC-AUTHN-007 и SEC-AUTHZ-002.

Клиент не должен самостоятельно разрешать операцию на основе данных из контролируемого им источника.

Обоснование¶

Клиент и его представления прав контролируются вызывающей стороной и не являются границей доверия.

Проверка¶

integration-тест обхода frontend и вызова API напрямую;
негативный тест доступа к чужому объекту и повышению привилегий;
review сокрытия действий в интерфейсе.

Исключения¶

Публичная операция должна быть явно объявлена публичной в контракте API.

FE-SEC-006. Целостность внешних скриптов¶

Уровень: MUST

Применяется к: скриптам и ресурсам, загружаемым из внешних источников

Внешний скрипт должен загружаться только из утверждённого источника, быть перечислен в allowlist и защищён Subresource Integrity (SRI), если это поддерживается форматом подключения. Состав внешних скриптов должен быть минимальным.

Реестр, consent, browser storage и отказоустойчивость стороннего кода регулируются FE-EXT-001–FE-EXT-003.

Обоснование¶

Внешний скрипт выполняется с полномочиями приложения; компрометация источника равноценна компрометации приложения.

Проверка¶

review allowlist и SRI внешних скриптов;
security-тест подмены источника;
проверка соответствия политике согласия.

Исключения¶

Внешний ресурс без поддержки SRI требует ADR с моделью угроз и компенсирующими мерами.

FE-SEC-007. Безопасность cross-origin взаимодействия¶

Уровень: MUST

Применяется к: postMessage, встраиванию во фрейм и cross-origin запросам

Получатель postMessage должен проверять origin сообщения и обрабатывать только ожидаемые источники. Политика frame-ancestors должна ограничивать допустимые источники встраивания, если встраивание не является назначением приложения.

Cross-origin запросы должны использовать CORS в соответствии с контрактом backend, не допуская передачи учётных данных произвольному источнику.

Обоснование¶

Непроверенный origin и неограниченное встраивание позволяют использовать приложение в атаке на пользователя.

Проверка¶

security-тест postMessage от неожиданного origin;
проверка frame-ancestors и CORS-политики;
review передачи учётных данных в cross-origin запросах.

Исключения¶

Приложение, предназначенное для встраивания на заданных доменах, фиксирует их перечень в политике.

FE-SEC-008. Защита от open redirect¶

Уровень: MUST

Применяется к: перенаправлению по URL из пользовательского ввода

Если приложение выполняет перенаправление по значению из параметра запроса, формы или иного пользовательского ввода, оно должно проверять цель по allowlist допустимых путей или схем и отвергать внешние адреса.

Redirect URI аутентификации должен точно совпадать с зарегистрированным значением по SEC-AUTHN-002.

Обоснование¶

Open redirect используется для фишинга и обхода доверия пользователя к домену.

Проверка¶

security-тест перенаправления на внешний URL;
review валидации цели перенаправления;
проверка зарегистрированных redirect URI.

Исключения¶

Не допускаются для перенаправления по непроверенному внешнему адресу.