Cross-Origin Resource Sharing (CORS) — механизм, использующий дополнительныеHTTP-заголовки, чтобы дать возможностьагенту пользователя получать разрешения на доступ к выбранным ресурсам с сервера на источнике (домене), отличном от того, что сайт использует в данный момент. Говорят, что агент пользователя делает запрос с другого источника(cross-origin HTTP request), если источник текущего документа отличается от запрашиваемого ресурса доменом, протоколом или портом.

Пример cross-origin запроса: HTML страница, обслуживаемая сервером сhttp://domain-a.com, запрашивает<img> src по адресуhttp://domain-b.com/image.jpg. Сегодня многие страницы загружают ресурсы вроде CSS-стилей, изображений и скриптов с разных доменов, соответствующих разным сетям доставки контента (Content delivery networks, CDNs).

В целях безопасности браузеры ограничивают cross-origin запросы, инициируемые скриптами. Например,XMLHttpRequest иFetch API следуютполитике одного источника (same-origin policy). Это значит, что web-приложения, использующие такие API, могут запрашивать HTTP-ресурсы только с того домена, с которого были загружены, пока не будут использованы CORS-заголовки.

Механизм CORS поддерживает кросс-доменные запросы и передачу данных между браузером и web-серверами по защищённому соединению. Современные браузеры используют CORS в API-контейнерах, таких какXMLHttpRequest илиFetch, чтобы снизить риски, присущие запросам с других источников.

Кто должен читать данную статью?

На самом деле, все.

Конкретнее, эта статья для web-администраторов, разработчиков серверной стороны и front-end разработчиков. Современные браузеры поддерживают клиентские компоненты cross-origin обмена, включая заголовки и соблюдение правил политики. Но этот новый стандарт означает, что сервера также должны поддерживать новые заголовки запросов и ответов. Другая статья для разработчиков серверной части, описывающаяперспективы cross-origin обмена на стороне сервера (с примерами кода на PHP), к дополнительному прочтению.

Какие запросы используют CORS?

Этотстандарт cross-origin обмена используется для разрешения кросс-сайтовых HTTP запросов для:

• ВызоваXMLHttpRequest илиFetch APIs в кросс-сайт манере, как описано выше.
• Web Fonts (для кросс-доменного использования шрифтов в@font-face в рамках CSS),чтобы серверы могли разворачивать TrueType шрифты, которые могут быть загружены только кросс-сайт и использованы web-сайтами, которым это разрешено.
• WebGL текстуры.
• Фреймы с изображениями/видео, добавленными в канвас с помощьюdrawImage.
• Стили (дляCSSOM доступа).
• Скрипты (для отключённых исключений).

Эта статья описывает общие понятия Cross-Origin Resource Sharing и включает обсуждение необходимых HTTP заголовков.

Обзор функциональности

Стандарт Cross-Origin Resource Sharing работает с помощью добавления новыхHTTP-заголовков, которые позволяют серверам описывать набор источников, которым разрешено читать информацию, запрашиваемую web-браузером. В частности, для методов HTTP-запросов, которые могут привести к побочным эффектам над данными сервера (в частности, для HTTP методов, отличных отGET или дляPOST запросов, использующих определённыеMIME-типы), спецификация требует, чтобы браузеры "предпроверяли" запрос, запрашивая поддерживающие методы с сервера с помощью метода HTTP-запросаOPTIONS и затем, поверх "подтверждения" с сервера, отсылали фактический запрос с фактическим методом HTTP-запроса. Сервера также могут оповещать клиентов должны ли "полномочия" (включаяCookies и HTTP Authentication данные) быть отправлены с запросом.

Следующая секция описывает сценарии, а также предоставляет анализ использования HTTP-заголовков.

Примеры сценариев управления доступом

Здесь мы рассмотрим три сценария, которые иллюстрируют как Cross-Origin Resource Sharing работает. Каждый сценарий использует объектXMLHttpRequest, который может быть использован для межсайтового взаимодействия, в любом, поддерживающем данный объект, браузере.

Фрагменты JavaScript-кода, включённые в эти секции (а также фрагменты кода, отвечающие за корректную обработку межсерверных запросов, которые запускаются на сервере) могут быть испытаны "в действии" наhttp://arunranga.com/examples/access-control/, и будут работать в браузерах, которые поддерживаютXMLHttpRequest.

Обсуждение Cross-Origin Resource Sharing с точки зрения сервера (включая фрагменты кода на PHP) может быть найдено в статьеServer-Side Access Control (CORS).

Простые запросы

Некоторые запросы не заставляют срабатыватьCORS preflight. Они называютсяпростыми запросами согласно устаревшейспецификации CORS (англ.), тогда какспецификация Fetch, которая в настоящее время определяет CORS, не использует данный термин.

«Простой запрос» — это запрос, удовлетворяющий следующим условиям:

• Допустимые методы для запроса:

  • GET
  • HEAD
  • POST

• Кроме заголовков, которые автоматически проставляются user-agent'ом (например,Connection,User-Agent, илилюбой другой заголовок с именем, определённым в спецификации метода Fetch в секции "Запрещённые имена заголовков (которые нельзя изменить программно)"), допустимыми заголовками, которые могут быть проставлены вручную, являютсяте заголовки, которые определены спецификацией метода Fetch как "CORS-безопасные заголовки запроса", такие как:

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (но учитывайте примечание ниже)

• Допустимыми значениями заголовкаContent-Type являются:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

• Не должны быть зарегистрированы обработчики событий на любой объектXMLHttpRequestUpload используемый в запросе; это достигается использованием свойстваXMLHttpRequest.upload.

• В запросе не должен использоваться объект типаReadableStream.

Например, представьте, что содержимое доменаhttp://foo.example хочет обратиться к содержимомуhttp://bar.other. На доменеhttp://foo.example может использоваться следующий Javascript код:

const xhr = new XMLHttpRequest();const url = "https://bar.other/resources/public-data/";xhr.open("GET", url);xhr.onreadystatechange = someHandler;xhr.send();

Это приведёт к простому обмену запросами между клиентом и сервером, используя CORS заголовки для обработки привилегий:

Посмотрим, что браузер отправит в таком случае на сервер, а также проверим ответ сервера:

GET /resources/public-data/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveReferer: http://foo.example/examples/access-control/simpleXSInvocation.htmlOrigin: http://foo.exampleHTTP/1.1 200 OKDate: Mon, 01 Dec 2008 00:23:53 GMTServer: Apache/2.0.61Access-Control-Allow-Origin: *Keep-Alive: timeout=2, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: application/xml[XML Data]

Строчки 1 - 10 это заголовки отправленного запроса. Самым интересующим здесь для нас заголовком являетсяOrigin, указанный на 10 строке. Данный заголовок указывает, что запрос пришёл из содержимого доменаhttp://foo.example.

Строчки 13 - 22 показывают HTTP-ответ от сервера на доменhttp://bar.other. В ответ сервер возвращаетAccess-Control-Allow-Origin заголовок, указанный на 16 строке. Использование заголовковOrigin header иAccess-Control-Allow-Origin показывает протокол контроля доступа в простейшем виде. В этом случае, сервер отвечает сAccess-Control-Allow-Origin: * что означает, что к ресурсу может получить доступ слюбого домена кросс-сайтовым способом. Владелец ресурсаhttp://bar.other может ограничить доступ к ресурсу для запросов только сhttp://foo.example, указав:

Access-Control-Allow-Origin: http://foo.example

Отметьте, никакой домен, кромеhttp://foo.example (определён ORIGIN: заголовок в запросе, как в 10 строке выше), не может получить доступ к ресурсу кросс-сайтовым способом. ЗаголовокAccess-Control-Allow-Origin должен содержать значение, которое было отправлено в заголовкеOrigin запроса.

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

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

В частности, запрос предварительно просматривается, если выполняетсялюбое из следующих условий:

• Если в запросе используется любой из следующих методов:

  • PUT
  • DELETE
  • CONNECT
  • OPTIONS
  • TRACE
  • PATCH

• Или если, кроме заголовков, автоматически устанавливаемых пользовательским агентом (например,Connection,User-Agent,или любым другим заголовком с именем, определённым в спецификации Fetch как "имя запрещённого заголовка"), запрос включает любые заголовки, отличные оттех, которые спецификация Fetch определяет как "заголовок запроса CORS-безопасный заголовок запроса", а именно:

  • Accept
  • Accept-Language
  • Content-Language
  • Content-Type (но учтите дополнительные требования ниже)
  • Last-Event-ID
  • DPR
  • Save-Data
  • Viewport-Width
  • Width

• Или если заголовокContent-Type содержит значение, отличное от следующих:

  • application/x-www-form-urlencoded
  • multipart/form-data
  • text/plain

• Или если один или больше обработчиков событий зарегистрированы на объектеXMLHttpRequestUpload, который используется в запросе.

• Или если объектReadableStream используется в запросе.

Ниже приведён пример запроса, который будет предварительно просмотрен.

var invocation = new XMLHttpRequest();var url = 'http://bar.other/resources/post-here/';var body = '<?xml version="1.0"?><person><name>Arun</name></person>';function callOtherDomain(){  if(invocation)    {      invocation.open('POST', url, true);      invocation.setRequestHeader('X-PINGOTHER', 'pingpong');      invocation.setRequestHeader('Content-Type', 'application/xml');      invocation.onreadystatechange = handler;      invocation.send(body);    }}......

В примере выше, 3 строка создаёт XML тело, чтобы отправитьPOST запросом на строке 8. Также, на строке 9, "кастомизированный" (не стандартный) заголовок HTTP запроса установлен (X-PINGOTHER: pingpong). Такие заголовки не являются частью протокола HTTP/1.1, но, как правило, полезны для веб-приложений. Так как запрос использует Content-Typeapplication/xml, и так как установлен кастомизированный заголовок, этот запрос просматривается.

Давайте посмотрим на полный обмен между клиентом и сервером. Первый обмен - этопредварительныйзапрос/ответ:

OPTIONS /resources/post-here/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveOrigin: http://foo.exampleAccess-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER, Content-TypeHTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:39 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400Vary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 0Keep-Alive: timeout=2, max=100Connection: Keep-AliveContent-Type: text/plain

Как только предварительный запрос завершён, отправляется настоящий запрос:

POST /resources/post-here/ HTTP/1.1Host: bar.otherUser-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3preAccept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateConnection: keep-aliveX-PINGOTHER: pingpongContent-Type: text/xml; charset=UTF-8Referer: http://foo.example/examples/preflightInvocation.htmlContent-Length: 55Origin: http://foo.examplePragma: no-cacheCache-Control: no-cache<?xml version="1.0"?><person><name>Arun</name></person>HTTP/1.1 200 OKDate: Mon, 01 Dec 2008 01:15:40 GMTServer: Apache/2.0.61 (Unix)Access-Control-Allow-Origin: http://foo.exampleVary: Accept-Encoding, OriginContent-Encoding: gzipContent-Length: 235Keep-Alive: timeout=2, max=99Connection: Keep-AliveContent-Type: text/plain[Some GZIP'd payload]

Строки 1 - 12 выше представляют предварительный запрос сOPTIONS методом. Браузер определяет, что ему нужно отправить это, основываясь на параметрах запроса, которые использовались во фрагменте кода JavaScript выше, чтобы сервер мог ответить, допустимо ли отправить запрос с фактическими параметрами запроса. OPTIONS - это метод HTTP/1.1, который используется для определения дополнительной информации от серверов, и являетсяsafe методом, что означает, что его нельзя использовать для изменения ресурса. Обратите внимание, что вместе с запросом OPTIONS отправляются два других заголовка запроса (строки 10 и 11 соответственно):

Access-Control-Request-Method: POSTAccess-Control-Request-Headers: X-PINGOTHER, Content-Type

ЗаголовокAccess-Control-Request-Method уведомляет сервер как часть предварительного запроса о том, что при отправке фактического запроса он будет отправлен методом запросаPOST. ЗаголовокAccess-Control-Request-Headers уведомляет сервер о том, что при отправке фактического запроса он будет отправлен с пользовательскими заголовкамиX-PINGOTHER и Content-Type. Теперь у сервера есть возможность определить, хочет ли он принять запрос в этих обстоятельствах.

Строки 14 - 26 выше - это ответ, который сервер отправляет обратно, указывая, что метод запроса (POST) и заголовки запроса (X-PINGOTHER) являются приемлемыми. В частности, давайте посмотрим на строки 17-20:

Access-Control-Allow-Origin: http://foo.exampleAccess-Control-Allow-Methods: POST, GET, OPTIONSAccess-Control-Allow-Headers: X-PINGOTHER, Content-TypeAccess-Control-Max-Age: 86400

Сервер отвечает сAccess-Control-Allow-Methods и сообщает, чтоPOST,GET, иOPTIONS являются жизнеспособными методами для запроса соответствующего ресурса. Обратите внимание, что этот заголовок похож на заголовок ответаAllow, но используется строго в контексте контроля доступа.

Сервер также отправляетAccess-Control-Allow-Headers со значением "X-PINGOTHER, Content-Type", подтверждая, что это разрешённые заголовки, которые будут использоваться с фактическим запросом. Как иAccess-Control-Allow-Methods,Access-Control-Allow-Headers представляет собой список допустимых заголовков через запятую.

Наконец,Access-Control-Max-Age даёт значение в секундах, в течение которого можно кешировать ответ на предварительный запрос без отправки другого предварительного запроса. В этом случае, 86400 секунды - это 24 часа. Обратите внимание, что каждый браузер имеетмаксимальное внутреннее значение, которое имеет приоритет, когдаAccess-Control-Max-Age больше.

Предварительные запросы и переадресации

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

Запрос был перенаправлен на 'https://example.com/foo', который запрещён для запросов из разных источников, требующих предварительной проверки

Запрос требует предварительной проверки, которая запрещена для перенаправления между источниками

Протокол CORS изначально требовал такого поведения, но впоследствиибыл изменён, чтобы больше не требовать его. Однако большинство браузеров ещё не реализовали это изменение и все ещё демонстрируют поведение, которое требовалось изначально.

Поэтому, пока браузеры не догонят спецификацию, вы можете обойти это ограничение, выполнив одно или оба из следующих действий:

• изменить поведение на стороне сервера, чтобы избежать предварительной проверки и/или избежать переадресации — если у вас есть контроль над сервером, к которому делается запрос
• изменить запрос так, чтобы это былпростой запрос, который не вызывает предварительную проверку

Но если невозможно внести эти изменения, то возможен другой способ:

1. Сделайтепростой запрос для определения (используяResponse.url для Fetch API, илиXHR.responseURL, чтобы определить, на каком URL завершится настоящий предварительный запрос).
2. Сделайте другой запрос ("настоящий" запрос), используя URL адрес, полученный вами изResponse.url илиXMLHttpRequest.responseURL на первом этапе.

Однако, если запрос инициирует предварительную проверку из-за наличия в запросе заголовкаAuthorization, вы не сможете обойти ограничение, используя описанные выше шаги. И вы вообще не сможете обойти это, если у вас нет контроля над сервером, на который делается запрос.

Запросы с учётными данными

Наиболее интересная возможность, предоставляемая какXMLHttpRequest, так иFetch и CORS - это возможность делать "проверенные" запросы, которые осведомлены о файлахHTTP cookie и информации HTTP аутентификации. По умолчанию, в кросс-сайтовыхXMLHttpRequest илиFetch вызовах, браузерыне отправляют учётные данные. Конкретный флаг должен быть установлен для объектаXMLHttpRequest или конструктораRequest при его вызове.

В этом примере контент, изначально загруженный изhttp://foo.example, выполняет простой GET запрос к ресурсуhttp://bar.other, который устанавливает файлы cookie. Содержимое на foo.example может содержать такой #"http://bar.other/resources/credentialed-content/";function callOtherDomain() { if (invocation) { invocation.open("GET", url, true); invocation.withCredentials = true; invocation.onreadystatechange = handler; invocation.send(); }}