Какие уязвимости существуют в фронтенд и бэкенд приложениях

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

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

Как отвечать

Опирайтесь на OWASP Top 10 и делите по месту, где уязвимость устраняется.

На клиенте:

• XSS: хранимый, отражённый и DOM-based. React экранирует вывод сам, дыры появляются через dangerouslySetInnerHTML, innerHTML, href со схемой javascript: и сторонние виджеты. Защита: DOMPurify, Content-Security-Policy, Trusted Types;
• хранение токенов: всё из localStorage прочитает любой внедрённый скрипт. Сессию лучше держать в cookie с HttpOnly, Secure и SameSite;
• clickjacking: страницу встраивают в чужой iframe, лечится frame-ancestors в CSP;
• секреты в бандле: всё с префиксом NEXT_PUBLIC_ или VITE_ уезжает в браузер открытым текстом;
• зависимости и postMessage: заражённый пакет из npm и обработчик сообщений без проверки event.origin.

На сервере:

• нарушение контроля доступа, включая IDOR: /orders/123 отдаёт чужой заказ, потому что сервер не сверил владельца;
• инъекции: SQL, NoSQL, команды ОС, лечатся параметризованными запросами;
• CSRF: чужой сайт шлёт запрос с cookie пользователя. Защищают SameSite, CSRF-токен и проверка Origin;
• остальное: SSRF, слабая аутентификация, открытые конфиги и отладочные эндпоинты.

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

Относят IDOR к фронтенду и предлагают спрятать кнопку. Скрытый элемент ничего не защищает, запрос можно отправить напрямую.

Называют CORS защитой API. CORS только ослабляет политику одного источника для браузера: запросы из curl он не останавливает и от CSRF не спасает.

Считают, что валидация формы на клиенте закрывает инъекции. Она про удобство, проверять данные всё равно обязан сервер.