---
title: HTTP и безопасность браузера
questionDates:
  q-transfer-0431: '2026-10-01'
  q-transfer-0432: '2026-10-01'
  q-transfer-0433: '2026-10-01'
  q-transfer-0455: '2026-10-01'
seo:
  description: >-
    Тема «HTTP и безопасность браузера» для собеседования React Developer.
    Почему запрос проходит в Postman, но блокируется браузером? Как CSP
    ограничивает выполнение стороннего кода в браузере?
  title: HTTP и безопасность браузера — React Developer
---

[Все темы React Developer](/prep/react-developer)

## Почему запрос проходит в Postman, но блокируется браузером? [#q-transfer-0431]

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

:::note[Ссылки для изучения]

1. [CORS: ограничения браузера, preflight и credentials](https://developer.mozilla.org/ru/docs/Web/HTTP/Guides/CORS)
   :::

---

## Как CSP ограничивает выполнение стороннего кода в браузере? [#q-transfer-0432]

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

:::note[Ссылки для изучения]

1. [CSP: заголовок и ограничение источников ресурсов](https://developer.mozilla.org/ru/docs/Web/HTTP/Guides/CSP)
   :::

---

## Чем опасен dangerouslySetInnerHTML? [#q-transfer-0433]

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

:::note[Ссылки для изучения]

1. [dangerouslySetInnerHTML и риск XSS](https://reactdev.ru/reference/react-dom/components/common/)
   :::

---

## От каких атак защищает флаг HttpOnly у cookie? [#q-transfer-0455]

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

:::note[Ссылки для изучения]

1. [HttpOnly: запрет JavaScript-доступа к cookie](https://developer.mozilla.org/ru/docs/Web/HTTP/Headers/Set-Cookie)
   :::