Какие существуют виды веб-атак кроме XSS

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

Знаете ли вы угрозы, от которых фронтенд защищается сам, а не только пересказ списка OWASP. Следом обычно спрашивают, как именно ваш код или заголовки ответа закрывают конкретную атаку.

Как отвечать

Начните с атак, где фронтенд прямой участник:

• CSRF: чужой сайт отправляет запрос от имени залогиненного пользователя, браузер сам прикладывает cookie. Защита: атрибут SameSite (Chrome трактует cookie без атрибута как Lax), CSRF-токен, проверка Origin;
• кликджекинг: ваш сайт открывают в прозрачном iframe и подсовывают клик. Закрывается Content-Security-Policy: frame-ancestors или X-Frame-Options;
• открытый редирект: параметр вроде ?next= уводит на фишинговый домен. Лечится белым списком адресов;
• prototype pollution: слияние пользовательского JSON в объект через ключ __proto__ меняет поведение всего приложения;
• атака через цепочку поставок: заражённый npm-пакет или скрипт с чужого CDN. Помогают lock-файл, npm audit, Subresource Integrity (атрибут integrity у <script>);
• перехват сессии и MitM: кража cookie или трафика. Нужны HTTPS с HSTS и флаги HttpOnly, Secure.

Затем назовите серверные атаки, о которых фронтендеру стоит знать: SQL-инъекции, SSRF, ошибки настройки CORS, DDoS. Их чинят на бэкенде, и проверка ввода на клиенте от них не спасает, это стоит сказать прямо.

Хороший финал: CSP как общий слой защиты, который сужает ущерб и от XSS, и от подгрузки чужих скриптов.

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

Считают CORS защитой от CSRF. CORS ограничивает чтение ответа, а простой POST из формы уходит на сервер и выполняется без всякого preflight.

Надеются на валидацию в браузере. Любой запрос можно отправить через curl в обход вашего интерфейса.

Хранят токен в localStorage и называют это безопасным. Любой XSS прочитает его одной строкой, а у cookie с HttpOnly такой возможности нет.