Какие типы атак бывают на фронтенд

Что проверяют

Отличаете ли вы атаки, которые реально проходят через клиентский код, от общих угроз вроде DDoS, и знаете ли защиту на уровне кода и заголовков. Следом обычно спрашивают, как React защищает от XSS и где эта защита заканчивается.

Как отвечать

• XSS: чужой скрипт исполняется на вашем origin. Бывает хранимый, отражённый и DOM-based, когда данные из location.hash или postMessage уходят в innerHTML. Защита: фреймворк экранирует текст по умолчанию, пользовательский HTML чистится DOMPurify, поверх ставится CSP с nonce и без unsafe-inline;
• CSRF: чужой сайт отправляет запрос с куками пользователя. Защита: SameSite=Lax или Strict на сессионной куке, CSRF-токен, проверка заголовка Origin на сервере;
• Clickjacking: ваш сайт грузят в невидимый iframe и подставляют под клик. Лечится директивой CSP frame-ancestors, старый вариант X-Frame-Options;
• атака на цепочку поставок: вредоносный npm-пакет или подменённый скрипт с CDN. Помогают lock-файл, npm audit, атрибут integrity (SRI) на внешних скриптах;
• open redirect: параметр ?next= уводит на фишинговый домен после логина, нужен белый список адресов;
• небезопасный postMessage: обработчик не проверяет event.origin, и любая вкладка шлёт ему команды;
• prototype pollution: глубокое слияние объектов с ключом __proto__ меняет поведение всего приложения.

Отдельно скажите про хранение токенов: всё, что лежит в localStorage, при XSS читается любым скриптом, а HttpOnly-кука скрипту недоступна.

Где спотыкаются

Называют DDoS и фишинг атаками на фронтенд. Это угрозы инфраструктуре и пользователю, код клиента их не решает, а HTTPS от фишинга не спасает: у поддельного сайта тоже есть сертификат.

Считают, что React полностью закрывает XSS. dangerouslySetInnerHTML, v-html во Vue и ссылка с пользовательским href вида javascript: остаются на вашей совести.

Защищаются от CSRF проверкой на клиенте или «двойной аутентификацией». Решение живёт на сервере и в атрибутах куки, скрытое поле в форме без проверки на бэкенде ничего не даёт.