Когда говорят о безопасности фронтенда, первым делом вспоминают XSS (cross-site scripting). https://set.ki/post/K9RCGZF (писал об этом здесь). Но если думать, что XSS это единственная проблема, можно упустить целый пласт других уязвимостей, которые могут быть не менее опасными.

❗️CSRF - это когда злоумышленник заставляет авторизованного пользователя выполнить действие на сайте без его ведома. Пользователь залогинен в банке, открывает вредоносный сайт, и тот отправляет запрос на перевод денег от его имени. Браузер автоматически подставляет cookies, и запрос выглядит легитимным. Защита строится на CSRF-токенах, которые проверяются на сервере, и SameSite cookies, которые не отправляются в cross-site запросах.

❗️Кликджекинг работает по-другому. Злоумышленник накладывает невидимый iframe поверх легитимного сайта. Пользователь думает, что кликает по кнопке «Получить приз», а на самом деле нажимает на кнопку «Перевести деньги» в банковском приложении, которое загружено в прозрачный iframe. Защита - правильная настройка заголовка X-Frame-Options, который запрещает встраивание страницы во фреймы, или CSP с директивой frame-ancestors.

❗️Открытые перенаправления кажутся безобидными, но могут привести к фишингу. Если приложение перенаправляет пользователя по URL из параметров запроса без проверки, злоумышленник может направить жертву на поддельный сайт, который выглядит как оригинальный. Пользователь вводит логин и пароль, думая, что находится на легитимном сайте. Решение - белый список разрешённых доменов для редиректов и валидация каждого URL перед перенаправлением.

❗️Раскрытие информации происходит через ошибки приложения, служебные заголовки или комментарии в коде. Заголовок X-Powered-By раскрывает технологию, Server - версию сервера, а детальные сообщения об ошибках могут содержать пути к файлам, SQL-запросы или другую чувствительную информацию. Нужно удалять лишние заголовки и настраивать защитные, например X-Content-Type-Options, который предотвращает MIME-sniffing атаки.

❗️IDOR возникает, когда приложение позволяет получать доступ к чужим данным, манипулируя идентификаторами в запросе. Если в URL есть /users/123/profile, и заменив 123 на 456 можно получить доступ к профилю другого пользователя, это уязвимость. Защита требует обязательной проверки прав доступа к запрашиваемому ресурсу на стороне сервера, а не только на клиенте.

❗️Утечка чувствительных данных - это когда номера карт, пароли или токены передаются в незащищённом виде или хранятся там, где их можно легко извлечь. Данные нужно маскировать при отображении, передавать только по HTTPS и никогда не хранить в LocalStorage или SessionStorage то, что не должно быть доступно через JavaScript. Для токенов аутентификации лучше использовать HttpOnly cookies.

❗️Ошибки конфигурации безопасности часто возникают из-за неправильной настройки окружения. Разные конфигурации для development и production, отсутствие необходимых переменных окружения, открытые debug-режимы в продакшене - всё это может стать точкой входа для атакующего. Важно строго разделять конфигурации для разных сред и проверять наличие всех необходимых переменных при старте приложения.

❗️Уязвимые зависимости - это когда в проекте используются библиотеки с известными уязвимостями. Современные приложения могут иметь тысячи зависимостей, и вручную отследить все уязвимости невозможно. Нужно регулярно обновлять пакеты, использовать инструменты для аудита вроде npm audit, и проверять целостность внешних ресурсов через SRI.

❗️Есть ещё Session Hijacking - перехват сессий через XSS, небезопасные соединения или session fixation. Защита - HttpOnly и Secure флаги для cookies, регенерация session ID после аутентификации, валидация IP и User-Agent на сервере.

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