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

Фронтенд часто считают «безопасным по умолчанию», хотя атакуют его через: • XSS через неэкранированный вывод • утечки токенов в localStorage • подмену зависимостей в npm. Давайте разберем под капотом: если пользовательский ввод попадает в DOM без санитайза, одна ошибка превращает страницу в точку входа.

Вторая зона риска — секреты в клиентском коде. Всё, что попало в бандл, можно извлечь. API-ключи, приватные URL, тестовые токены — это не защита, а задержка до первого просмотра исходников. Для чувствительных операций нужен серверный прокси и короткоживущие токены.

Третья проблема — цепочка поставки. Проверяйте lockfile, ставьте аудит зависимостей, фиксируйте версии и убирайте лишние пакеты. Если библиотека нужна только ради одной функции, лучше вынести её вручную, чем тащить десятки транзитивных зависимостей. Что по производительности? Меньше пакетов — меньше и атакуемая поверхность.

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