PassFront
  1. PassFront
  2. База знаний
  3. DOM и браузер

Какие уязвимости возникают при запрете кросс-доменных запросов?

DOM и браузер

Запрет кросс-доменных запросов (Same-Origin Policy) сам по себе защищает, но его обход/ослабление (широкий CORS ``, отключение проверок) открывает уязвимости: утечку данных, CSRF-подобные атаки, доступ к API.**

Контекст

Same-Origin Policy (SOP) запрещает чтение ответов кросс-доменных запросов — это защита. Уязвимости возникают при её неправильном ослаблении (настройка CORS).

Уязвимости при неверной настройке

Слишком широкий CORS

Access-Control-Allow-Origin: * на приватном API → любой сайт может читать данные пользователя:

Access-Control-Allow-Origin: *  # опасно для приватных данных

Credentials с широким origin

Разрешение credentials с отражением любого origin → чужой сайт с cookie пользователя читает приватные ответы:

Access-Control-Allow-Origin: <любой>
Access-Control-Allow-Credentials: true  # уязвимость

Отражение Origin без проверки

Сервер бездумно возвращает Allow-Origin = запрошенный origin → фактически разрешает всем.

Отключение SOP/CORS

Отключение проверок «для удобства» открывает утечку данных.

Что это даёт злоумышленнику

  • Чтение приватных данных пользователя через его сессию.
  • Обход изоляции origin.
  • Доступ к внутренним API.

Как правильно

  • Разрешать только доверенные origin (белый список), не * для приватных API.
  • При credentials — конкретный origin, проверять Origin.
  • Не отключать SOP.

Коротко для собеседования

Сам запрет кросс-доменных запросов (SOP) защищает; уязвимости — при неправильном ослаблении CORS: Allow-Origin: * на приватном API (любой сайт читает данные), credentials с отражением любого origin (чужой сайт с cookie читает приватное), бездумное отражение Origin. Это даёт утечку данных и доступ к API. Правильно — белый список доверенных origin, не * для приватного.

Другие вопросы раздела