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

Если конфигурация CORS настроена неправильно, в консоли браузера появится ошибка, например "Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at [some site]", указывающая, что запрос заблокирован из-за нарушения правил безопасности CORS. Однако это не обязательно означает, что конфигурация настроена неверно. Возможно, веб-приложение пользователя и удалённый внешний сервис намеренно запрещают этот запрос. Но если конечная точка должна быть доступна, потребуется отладка.

Определение проблемы CORS

Чтобы понять, в чём заключается проблема конфигурации CORS, нужно выяснить, какой запрос вызывает ошибку и почему. В этом могут помочь следующие шаги:

1. Перейдите на нужный веб-сайт или в веб-приложение и откройте инструменты разработчика.
2. Теперь попробуйте воспроизвести неудачную операцию и проверьте консоль, чтобы узнать, отображается ли сообщение об ошибке нарушения CORS. Вероятно, оно будет выглядеть так:

Текст сообщения об ошибке будет примерно таким:

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).

Что можно сделать на стороне клиента

Большинство ошибок CORS можно устранить только на сервере, поскольку именно сервер определяет, разрешён ли междоменный доступ. Тем не менее на стороне клиента можно предпринять некоторые действия:

Избегайте предварительного запроса

При выполнении определённых условий (пользовательские заголовки, методы, отличные от GET/HEAD/POST, или нестандартные типы содержимого) браузеры отправляют предварительный запрос перед фактическим запросом. Если сервер не обрабатывает предварительные запросы, можно изменить структуру запроса, чтобы он соответствовал требованиям простого запроса:

• Используйте только методы GET, HEAD или POST.
• Указывайте только заголовки запросов, входящие в список разрешённых CORS (например, Accept, Content-Language или Content-Type).
• Для заголовка Content-Type используйте только application/x-www-form-urlencoded, multipart/form-data или text/plain.

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

Используйте режим no-cors для непрозрачных ответов

Если вам не нужно читать тело ответа или его заголовки — например, при отправке аналитических маяков или загрузке ресурсов в кэш с помощью сервис-воркера, — можно задать для mode значение "no-cors" в вызове fetch():

fetch("https://api.example.com/log", {
  method: "POST",
  mode: "no-cors",
  body: data,
});

Ответ будет непрозрачным: его статус — 0, заголовки пусты, а тело недоступно для чтения JavaScript. Так задумано: no-cors отключает проверку CORS, но взамен вы теряете доступ ко всему содержимому ответа.

Используйте прокси-сервер

Если вы не контролируете удалённый сервер и он не устанавливает заголовки CORS, можно направлять запросы через сервер, который вы контролируете. Ваш сервер получает ресурс от вашего имени и возвращает его с соответствующими заголовками CORS. Такой подход увеличивает задержку и создаёт зависимость от прокси, но подходит, когда другие варианты недоступны.

Сообщения об ошибках CORS

Если запросы завершаются ошибкой из-за CORS, в консоли Firefox отображаются соответствующие сообщения. В тексте ошибки есть сообщение «причина», которое помогает понять, что пошло не так. Ниже приведены сообщения о причинах; нажмите на сообщение, чтобы открыть статью с более подробным объяснением ошибки и возможными решениями.

• Причина: CORS отключён
• Причина: запрос CORS не выполнен
• Причина: заголовок CORS 'Origin' невозможно добавить
• Причина: внешний перенаправленный запрос CORS не разрешён
• Причина: запрос CORS не использует HTTP
• Причина: отсутствует заголовок CORS 'Access-Control-Allow-Origin'
• Причина: значение заголовка CORS 'Access-Control-Allow-Origin' не соответствует 'xyz'
• Причина: учетные данные не поддерживаются, если значение заголовка CORS 'Access-Control-Allow-Origin' равно '*'
• Причина: метод не найден в заголовке CORS 'Access-Control-Allow-Methods'
• Причина: в заголовке CORS 'Access-Control-Allow-Credentials' ожидалось значение 'true'
• Причина: предварительный запрос CORS не выполнен
• Причина: недопустимый токен 'xyz' в заголовке CORS 'Access-Control-Allow-Methods'
• Причина: недопустимый токен 'xyz' в заголовке CORS 'Access-Control-Allow-Headers'
• Причина: в предварительном запросе CORS отсутствует токен 'xyz' в заголовке CORS 'Access-Control-Allow-Headers'
• Причина: несколько заголовков CORS 'Access-Control-Allow-Origin' не допускаются

Большинство ошибок CORS можно устранить только на сервере, поскольку именно сервер определяет, разрешён ли междоменный доступ. Тем не менее на стороне клиента можно предпринять некоторые действия:

Избегайте предварительного запроса

При выполнении определённых условий (пользовательские заголовки, методы, отличные от GET/HEAD/POST, или нестандартные типы содержимого) браузеры отправляют предварительный запрос перед фактическим запросом. Если сервер не обрабатывает предварительные запросы, можно изменить структуру запроса, чтобы он соответствовал требованиям простого запроса:

• Используйте только методы GET, HEAD или POST.
• Указывайте только заголовки запросов, входящие в список разрешённых CORS (например, Accept, Content-Language или Content-Type).
• Для заголовка Content-Type используйте только application/x-www-form-urlencoded, multipart/form-data или text/plain.

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

Используйте режим no-cors для непрозрачных ответов

Если вам не нужно читать тело ответа или его заголовки — например, при отправке аналитических маяков или загрузке ресурсов в кэш с помощью сервис-воркера, — можно задать для mode значение "no-cors" в вызове fetch():

fetch("https://api.example.com/log", {
  method: "POST",
  mode: "no-cors",
  body: data,
});

Ответ будет непрозрачным: его статус — 0, заголовки пусты, а тело недоступно для чтения JavaScript. Так задумано: no-cors отключает проверку CORS, но взамен вы теряете доступ ко всему содержимому ответа.

Используйте прокси-сервер

Если вы не контролируете удалённый сервер и он не устанавливает заголовки CORS, можно направлять запросы через сервер, который вы контролируете. Ваш сервер получает ресурс от вашего имени и возвращает его с соответствующими заголовками CORS. Такой подход увеличивает задержку и создаёт зависимость от прокси, но подходит, когда другие варианты недоступны.

См. также

• Глоссарий: CORS
• Введение в CORS
• Настройки CORS на стороне сервера
• Изображение с поддержкой CORS
• Атрибуты настроек CORS