HTTP и безопасность браузера

Все темы React Developer

Почему запрос проходит в Postman, но блокируется браузером?

Postman не применяет браузерную модель same-origin, а JavaScript страницы применяет. Если origin отличается схемой, host или port, браузер проверяет CORS-заголовки ответа. Для некоторых методов и заголовков он сначала отправляет preflight OPTIONS; сервер должен разрешить origin, метод и headers. При credentials нельзя использовать Access-Control-Allow-Origin: *, нужен конкретный origin и разрешение credentials. CORS обычно не мешает запросу дойти до сервера, но может запретить скрипту прочитать ответ. Это не защита API от Postman или серверного клиента, поэтому авторизация нужна независимо.

Как CSP ограничивает выполнение стороннего кода в браузере?

CSP задаётся HTTP-заголовком и ограничивает источники ресурсов. script-src определяет допустимые скрипты; nonce или hash позволяют запускать конкретный inline-код без широкого unsafe-inline. connect-src ограничивает fetch, WebSocket и другие подключения. Сначала политику удобно включить через Content-Security-Policy-Report-Only, собрать нарушения и затем сделать блокирующей. CSP снижает последствия XSS, но не исправляет уязвимый рендеринг и не делает доверенный сторонний скрипт безопасным. Политика должна быть узкой, иначе разрешённый origin или unsafe-eval оставит обход.

Чем опасен dangerouslySetInnerHTML?

dangerouslySetInnerHTML передаёт строку прямо в HTML parser и обходит обычное экранирование React. Если в строку попал пользовательский или внешний HTML, атакующий может внедрить XSS через поддерживаемые браузером конструкции. Допустимый случай: контент из контролируемого источника после санитизации библиотекой с явной политикой разрешённых тегов и атрибутов. Санитизацию делают на границе получения данных и сохраняют происхождение доверенного значения; фильтр на regex недостаточен. CSP и Trusted Types уменьшают риск, но не превращают произвольную строку в безопасную. Для обычного текста используют JSX-интерполяцию.

От каких атак защищает флаг HttpOnly у cookie?

HttpOnly запрещает JavaScript читать cookie через document.cookie, поэтому XSS сложнее украсть сам токен. Браузер всё равно автоматически отправляет cookie подходящему origin, значит вредоносный скрипт может выполнять запросы от имени пользователя, а CSRF остаётся отдельным риском. Secure разрешает передачу только по HTTPS. SameSite ограничивает отправку в cross-site-контексте и имеет режимы Strict, Lax, None; для None современные браузеры требуют Secure. Эти флаги дополняют экранирование, CSP, CSRF-токены и короткие сессии, а не заменяют их.