CORS: Объяснение кросс-оригинального обмена ресурсами

Это строго запрещено: Если вы заходите на сайт, вы не должны получать дополнительные данные со сторонних серверов! Но могут быть и исключения. Если оба владельца веб-сайта согласны на сотрудничество, ничто не мешает им прийти к соглашению. Кросс-оригинальный обмен ресурсами (CORS) регулирует это сотрудничество. Как это работает?

Политика одинакового происхождения (SOP) запрещает загрузку с других серверов при посещении веб-сайта. Все данные должны поступать из одного источника, т.е. происходить с одного сервера. Это мера безопасности, поскольку JavaScript и CSS могут загружать содержимое с других серверов без ведома пользователя — в том числе вредоносное содержимое. Такая попытка доступа называется кросс-оригинальным запросом. Однако, если обмен данными известен как операторам сайта, так и его назначению, то процедура может быть разрешена. Тогда запрашиваемый сервер — то есть сервер, с которого должно быть загружено содержимое — разрешает доступ через кросс-оригинальный обмен ресурсами.

Однако это происходит только для определенных клиентов. Это означает: CORS не является открытым приглашением для любых кросс-оригинальных запросов. Вместо этого второй сервер разрешает эксклюзивный доступ первому через заголовок HTTP. Заголовок HTTP-ответа точно описывает, какой сервер может загрузить данные и сделать их окончательно доступными для пользователя. Общее разрешение на доступ для всех клиентов разрешается только путем интеграции подстановочных знаков. Однако это имеет смысл только для серверов, предлагающих такую информацию, которая должна быть доступна широкой публике — например, веб-шрифты.

В идеале пользователь не должен замечать обмена между двумя задействованными серверами. Все современные браузеры поддерживают кросс-оригинальный обмен ресурсами, и отправка запросов и ответов происходит в фоновом режиме максимально быстро при обращении к веб-сайту.

В соответствии с политикой same-origin, сведения о происхождении соединения с сервером состоят из трех элементов: хост, порт и протокол. В приведенном выше примере директива запрещает сайту ‘https://example.com’ обращаться к сайту ‘http://example.com’ или ‘https://example.org’. В первом случае протокол не одинаков, во втором — информация о хосте не идентична.

Кросс-оригинальный запрос — это, по сути, HTTP-запрос. Определенные методы обычно не представляют проблем. GET и HEAD не могут изменять данные и поэтому обычно не воспринимаются как угроза безопасности. Иная ситуация с PATCH, PUT или DELETE: они делают возможным вредное вмешательство. По этой причине здесь также должно быть активировано кросс-оригинальное совместное использование ресурсов. Соответственно, CORS может включать не только информацию о разрешенном происхождении, но и о том, какие HTTP-запросы разрешены источником.

Если это HTTP-методы, имеющие отношение к безопасности, клиент первоначально отправляет предварительный запрос. Он только указывает, какой метод HTTP будет следующим направлен на сервер, и спрашивает, будет ли запрос считаться безопасным. Для этого используется заголовок OPTIONS. Только после положительного ответа может быть выполнен фактический запрос.

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

• Access-Control-Allow-Origin: Какое происхождение разрешено?
• Access-Control-Allow-Credentials: Разрешены ли запросы, даже если режим учетных данных установлен на include?
• Access-Control-Allow-Headers: Какие заголовки могут быть использованы?
• Access-Control-Allow-Methods: Какие методы запроса HTTP разрешены?
• Access-Control-Expose-Headers: Какие заголовки могут быть отображены?
• Access-Control-Max-Age: Каким может быть возраст запроса на префлайт, прежде чем он истечет?
• Access-Control-Request-Headers: Какой HTTP-заголовок указывается в запросе предварительной проверки?
• Access-Control-Request-Method: Какой метод HTTP указан в запросе предпросмотра?
• Origin: Что является источником запроса?

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

В нашем примере ниже мы предполагаем, что хост A (example.com) хочет отправить запрос DELETE на хост B (example.org). Для этого исходный сервер сначала посылает предварительный запрос:

Если у хоста B нет проблем с этим кросс-оригинальным запросом, он отвечает соответствующими CORS-заголовками:

Если заголовки в ответе не соответствуют спецификациям запроса, или если запрашиваемый сервер не отвечает, кросс-оригинальный запрос не может быть выполнен.

CORS служит для обхода безопасной по своей сути настройки по умолчанию — а именно политики одноименного происхождения. SOP, в свою очередь, является эффективным способом предотвращения потенциально опасных соединений. Однако интернет часто основан на таких перекрестных запросах, поскольку во многих случаях многие соединения от одного узла к другим, безусловно, желательны.

Поэтому CORS предлагает промежуточный маршрут: Для ситуаций, в которых явно требуются кросс-оригинальные запросы, с помощью CORS можно сделать исключения. Однако существует риск, что владельцы сайтов будут просто использовать подстановочные знаки из соображений удобства. Это сведет на нет любую защиту со стороны СОРС. Вот почему важно использовать CORS только в отдельных особых случаях и настраивать его как можно более ограничительно.