Безопасность фронтенда ломается не в коде, а на стыке сборки, API и DOM

Безопасность фронтенда ломается не в коде, а на стыке сборки, API и DOM

Фронтенд часто считают «безопасным по умолчанию»: есть React, шаблонизатор, CSP — значит, риск закрыт. На практике уязвимости обычно появляются в трех местах: • вставка внешнего HTML без санитайза • хранение токенов в доступном JS-слое • доверие к данным из query string, localStorage и postMessage.

Давайте разберем под капотом. Самые частые проблемы: XSS через dangerouslySetInnerHTML/innerHTML, подмена redirect-параметров, утечки секретов в bundle, а также supply-chain риски в npm-зависимостях. Любой публичный ключ в коде — не секрет, а любой «временный» обход CSP со временем становится постоянным.

Что делать на практике: • экранировать вывод по умолчанию • разрешать HTML только через whitelist-санитайзер • не хранить access token в localStorage, если можно обойтись HttpOnly-cookie • жестко проверять origin у postMessage • собирать bundle без лишних env-переменных • подключать SRI для внешних скриптов.

Вердикт для продакшена: безопасный фронтенд — это не библиотека, а набор ограничений. Чем меньше доверия к входным данным и сторонним скриптам, тем меньше сюрпризов в интерфейсе и на бэкенде.