Приходилось ли работать с безопасностью приложения

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

Отличаете ли вы свою зону ответственности от серверной. Фронтенд не может быть границей доверия, и интервьюер хочет услышать, что вы это понимаете: браузер защищает пользователя от чужого кода, а данные защищает сервер.

Как отвечать

Опишите, за что отвечает клиент, и назовите механизмы:

• межсайтовый скриптинг: экранирование по контексту. Фреймворки экранируют текст сами, дыру открывают вставка сырой разметки через свойства вроде innerHTML и ссылки с произвольной схемой. Пользовательский HTML пропускают через санитайзер;
• заголовок Content-Security-Policy: запрет произвольных инлайн-скриптов и сторонних источников, это второй рубеж на случай, если экранирование где-то пропустили;
• сессия: токен в куке с флагами HttpOnly, Secure и SameSite, а не в хранилище браузера;
• подделка запросов: SameSite плюс отдельный токен, если авторизация идёт куками;
• зависимости: зафиксированный lock-файл, аудит пакетов, осторожность с малоизвестными библиотеками в бандле.

Уместно добавить, что CORS это не защита, а правила чтения ответа чужим источником: сервер всё равно обязан проверять права на каждый запрос.

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

Называют клиентскую валидацию защитой. Проверка формы в браузере это удобство для пользователя, обойти её можно через консоль или обычный HTTP-клиент, поэтому те же правила обязаны быть продублированы на сервере.

Хранят токен доступа в локальном хранилище и уверяют, что так безопаснее кук. Любой выполненный на странице скрипт читает это хранилище, а куку с флагом HttpOnly не достанет; риск подделки запросов закрывается флагом SameSite и токеном, а не переездом в хранилище.

Путают кодирование с защитой. Base64, минификация и обфускация ничего не скрывают, а переменные сборки фронтенда попадают в бандл как есть: приватный ключ, положенный в такую переменную, публичен с момента выкладки.