Видели это раньше? Скорее всего… и, наверное, много раз…

Существуют миллионы статей, объясняющих, как исправить эту ошибку, но что такое это «Совместное использование ресурсов между разными источниками» (Cross-Origin Resource Sharing, CORS) и зачем оно вообще нужно?

Почему?

Давайте начнём с ответа на вопрос «почему?» через сценарий и посмотрим, как это могло бы происходить в разные моменты времени.

Представьте: вы заходите на bank.com — ваш банковский сервис. После входа в систему в вашем браузере сохраняется «сессионная кука» (session cookie). (Сессионные куки, по сути, сообщают серверу bank.com, что ваш браузер теперь авторизован в вашем аккаунте.) Все последующие запросы к bank.com будут содержать эту куку, и сервер сможет корректно отвечать, зная, что вы вошли в систему.

Теперь вы решаете проверить свою почту. Вы видите подозрительное письмо и, конечно же, решаете перейти по ссылке внутри, которая ведёт на attack.com. Затем этот сайт отправляет запрос к bank.com, чтобы получить данные вашего банковского счёта. Учтите, что bank.com всё ещё считает, что вы авторизованы, благодаря той самой сессионной куке… которая хранится в вашем браузере. Для серверов bank.com это выглядит так, будто вы запросили свои банковские данные в обычном режиме, поэтому они отправляют их обратно. Теперь attack.com получает доступ к этим данным и может использовать их в злонамеренных целях.

Люди поняли, что это плохо, поэтому браузеры внедрили SOP (Same-Origin Policy, политика одинакового происхождения). Если браузер замечает, что вы пытаетесь отправить запросы к bank.com с какого-либо сайта, кроме самого bank.com, он блокирует их. Здесь важно понимать, что это политика на уровне браузера. Сам bank.com не может определить, откуда пришёл запрос, поэтому он не может защититься от атак, таких как CSRF (межсайтовая подделка запроса). Браузер, который вы используете, вмешивается и, по сути, говорит: если вы пытаетесь запросить данные для определённого источника (схема + доменное имя + порт, например, https://foo.com:4000, http://bar.org:3000 и т.д., то есть URL), он отправит эти запросы только для одинаковых источников.

Это было здорово, но очень ограничительно. Публичные API вообще не работали. Вы не могли запрашивать данные из них, если не использовали какое-либо прокси-решение.

CSRF

Вот в чём дело: серверы могут примерно определить, откуда пришёл запрос. Существует заголовок «Origin», который должен быть в запросах, и он указывает, с какого источника был сделан запрос. Например, в вышеуказанном примере запрос мог бы выглядеть примерно так.

	
Request to -----> bank.com
{
  Headers: { Origin: http://attack.com }
}
	

Теоретически, bank.com должен проверять этот заголовок, чтобы убедиться, что отвечает только на запросы, где источник имеет смысл. И обычно так и происходит, поэтому SOP (Политика одного источника) кажется несколько ограничивающей.

Вот здесь на сцену выходит CORS.

CORS

Когда веб-приложение с сайта example.com пытается запросить ресурсы с сайта bank.com, браузер автоматически добавляет заголовок Origin в запрос, указывая, откуда этот запрос исходит (example.com). Вот ключевой момент: вместо того чтобы полностью блокировать такие межсайтовые запросы в соответствии с политикой SOP (Same-Origin Policy), сервер bank.com может проверить этот заголовок Origin и решить, разрешить или отклонить запрос на основе своей политики CORS.

Если bank.com считает example.com доверенным или запрашиваемый ресурс предназначен для публичного доступа, он может ответить с определёнными заголовками CORS, такими как Access-Control-Allow-Origin, указывая, какие источники могут получить доступ к ресурсу. Этот заголовок может быть установлен на http://example.com, явно разрешая доступ для этого источника, или на * для публичных ресурсов, доступных для любого источника.

. Конечно, всё это обеспечивается браузером. Если что-то пойдёт не так, вы получите неприятную ошибку.

А что, если запрос не содержит заголовка Origin? Или если в нём есть множество других заголовков и используются нестандартные HTTP-методы?

В таких ситуациях обработка CORS становится немного сложнее, так как это уже не «простой запрос». Здесь в игру вступает концепция «предварительных запросов» (preflight requests) в CORS.

Предварительный запрос (Preflight)

Для определённых типов запросов, которые потенциально могут изменять данные на сервере (например, запросы с использованием HTTP-методов PUT, DELETE или с заголовками, которые не включаются автоматически в каждый запрос), браузеры сначала отправляют предварительный запрос (preflight) перед тем, как выполнить основной запрос. Этот предварительный запрос представляет собой HTTP-запрос с методом OPTIONS, и его цель — проверить у сервера, безопасно ли отправлять основной запрос.

Предварительный запрос включает заголовки, которые описывают HTTP-метод и заголовки основного запроса. Вот что происходит дальше:

1. Ответ сервера: Если сервер поддерживает политику CORS и разрешает основной запрос, он отвечает на предварительный запрос заголовками, указывающими, какие методы и заголовки разрешены. Это могут быть заголовки, такие как `Access-Control-Allow-Methods` и `Access-Control-Allow-Headers`.
2. Решение браузера: На основе ответа сервера на предварительный запрос браузер решает, следует ли выполнять основной запрос. Если ответ сервера указывает, что запрос разрешён, браузер отправляет его; если нет, браузер блокирует запрос, и вы увидите ошибку, связанную с CORS.

Заключение

Теперь, надеюсь, вы понимаете немного больше о CORS. Я думаю, самое важное — осознать, что это всё политика браузера, и ваш сервер должен быть запрограммирован так, чтобы ей соответствовать. Она существует для вашей безопасности. Если вы используете Chrome или другой браузер, вам не стоит слишком беспокоиться о переходе по неправильным ссылкам (хотя, конечно, всё же стоит немного осторожничать). Однако это не абсолютно надёжная защита.

Если вы используете какой-то сторонний браузер, который не соответствует стандартам, всё это теряет смысл. Именно поэтому важно быть внимательным к тому, какое программное обеспечение вы используете!