Принято считать, что безопасность — это зона бэкенда.
Фронтенд «просто отправляет запросы и рендерит UI».
На практике фронтенд напрямую влияет на то,
будет приложение безопасным или нет.
CORS — это не про «разрешить запрос»
CORS часто воспринимают как настройку:
«чтобы запросы не падали из браузера».
Но по сути это механизм, который говорит:
кто имеет право читать ответ.
Важно понимать:
👉 сервер может обработать запрос
👉 но браузер может не дать прочитать ответ
Именно поэтому:
👉
Access-Control-Allow-Origin: * — не «фикс», а потенциальная дыра 👉
credentials + wildcard — запрещённая комбинация
CORS — это про контроль доступа, а не про обход ошибок.
CSP — ваш последний рубеж
Content Security Policy — это защита от XSS,
даже если у вас уже есть уязвимость.
Пример:
Content-Security-Policy: default-src 'self'; script-src 'self'
Что это даёт:
👉 запрещает выполнение inline-скриптов
👉 блокирует загрузку скриптов с чужих доменов
👉 режет целый класс атак
Но есть нюанс.
Если CSP выглядит так:
script-src * 'unsafe-inline' 'unsafe-eval'
Это не защита. Это иллюзия.
Security headers, которые реально важны
👉
X-Content-Type-Options: nosniff Браузер не пытается угадать тип файла. Меньше атак через подмену.
👉
X-Frame-Options / frame-ancestors Защита от clickjacking.
👉
Strict-Transport-Security (HSTS) Принудительный HTTPS. Без вариантов.
👉
Referrer-Policy Контроль того, какие данные уходят при переходах.
Где фронтендер влияет напрямую
👉 какие скрипты подключаются
👉 есть ли inline JS
👉 используются ли eval-подобные вещи
👉 как работают сторонние виджеты
👉 как обрабатываются пользовательские данные
Можно иметь идеальный бэкенд и сломать всё на уровне UI.
Частая ошибка
«Мы включили CSP — значит всё ок».
Но:
👉 нет nonce / hash
👉 разрешены любые источники
👉 подключены сторонние скрипты без контроля
В итоге защита есть только на бумаге.
Главная мысль
CSP, CORS и заголовки — это не чекбокс в настройках.
Это часть архитектуры.
Если фронтенд не понимает, как они работают,
безопасность становится случайностью.
