CORS: Что это такое и зачем оно нам нужно?

Совместное использование ресурсов между источниками — это протокол, который позволяет клиенту из одного источника взаимодействовать с ресурсами, находящимися в другом источнике. Когда мы говорим о ресурсах, это такие вещи, как вызовы API для получения некоторых данных, загрузка изображений, значков и т. д. Нам нужен CORS, чтобы перезаписать политику того же происхождения, за которой следуют XMLHttpRequest и fetch. Это означает, что Javascript может совершать вызовы только к URL-адресам, размещенным в том же источнике (домене), что и сам скрипт. Однако есть много сценариев, когда мы хотели бы использовать службы, принадлежащие другому домену, и в таких сценариях нам пригодится cors.

Политика того же происхождения

Браузеры реализуют механизм безопасности, называемый политикой того же происхождения. Эта политика была реализована для борьбы с одной из самых распространенных кибератак: подделкой межсайтовых запросов. Во время подделки межсайтовых запросов злоумышленник/веб-сайт пытается взломать систему файлов cookie браузера и попытаться украсть ресурсы от имени подлинного веб-сайта.

Политика браузера в отношении файлов cookie. Каждый раз, когда браузер делает HTTP-запрос к домену, он прикрепляет все файлы cookie, хранящиеся в браузере и относящиеся к этому домену. Это полезно для аутентификации и для установления сеанса. Например: когда вы входите в https://example.com, сервер устанавливает определенные файлы cookie, связанные с сеансом, для домена https://example.com в браузере. Каждый раз, когда вы повторно посещаете https://example.com или выполняете какие-либо API-вызовы https://example.com, файлы cookie сеанса будут отправляться вместе с запросом. API распознает этот файл cookie и разрешит доступ без повторного входа в систему.

Поскольку браузер автоматически прикрепляет все соответствующие файлы cookie домена во время любого запроса, вредоносный веб-сайт попытается отправить запросы на https://example.com из браузера. В таком случае будут отправлены файлы cookie, хранящиеся в браузере для домена https://example.com. Если файлы cookie действительны, вредоносный веб-сайт получает доступ к https://example.com и его ресурсам. Таким образом, учетная запись пользователя будет подвергнута атаке с подделкой межсайтовых запросов.

Чтобы предотвратить это, в браузерах реализована политика того же происхождения. Это означает, что любые запросы, сделанные из браузера с данного веб-сайта на тот же домен, будут разрешены. Это остановит запросы, поступающие из другого домена в соответствии с политикой same-origin.

Почему браузеры выдают ошибку CORS? Мы знаем, что запросы между источниками обычно блокируются браузерами из соображений безопасности. Веб-сервер не только содержит общедоступные ресурсы, такие как изображения и шрифты, но также содержит конфиденциальную информацию, такую ​​как личная информация пользователя. Эти веб-серверы иногда предоставляют общедоступные API для других веб-сайтов, чтобы они могли использовать их ресурсы и взаимодействовать с ними. Это может быть форма обслуживания, предоставляемого одним сервером другому. Ниже приведены несколько причин, по которым браузеры обычно блокируют запросы из разных источников:

  • Запрашиваемый API не позволяет обмениваться ресурсами между источниками
  • Предоставленный API позволяет определенным квалифицированным доменам обмениваться ресурсами между источниками
  • API требует отправки определенных заголовков, чтобы разрешить общий доступ к ресурсам из разных источников

Ошибки CORS и способы их устранения

Если вы какое-то время занимались веб-разработкой, я уверен, что вы сталкивались со следующей ошибкой:

Каждый раз, когда вы пытались работать с внешними API, вы могли сталкиваться с этой ошибкой. Возможно, вы также пытались отправить заголовки, такие как 'Access-Control-Allow-Headers': '*', 'Access-Control-Allow-Origin': '*', 'Access-Control-Allow-Credentials': true, вместе с запросом, и вам не удалось устранить ошибку CORS:

В большинстве случаев эту ошибку можно устранить, добавив определенные заголовки, такие как Access-Control-Allow-Origin: "https://example.com". По сути, это означает, что сервер API, размещенный в другом домене, доверяет нашему домену и готов поделиться своими ресурсами. API-интерфейсы созданы для общей цели, и API-интерфейсы не могут начинать заносить в белый список каждый новый домен, который появляется в Интернете. Кроме того, нет никакой гарантии, что домен, установивший доверие сегодня, не станет вредоносным завтра.

Итак, что теперь делать? Мы сдаемся? Каковы способы решения этой проблемы?

Существует несколько способов устранения ошибки cors:

1. Установка плагинов Allow-origin в браузере:

Если вы только тестируете API и хотите использовать его данные, не затрагивая проблему CORS, можно установить плагин CORS и выполнять вызовы API из браузера, как если бы он запрашивал ресурсы из того же домена. Обратите внимание, что плагин предназначен только для исправления на вашем локальном компьютере. Плагин, по сути, добавит заголовок Access-Control-Allow-Origin: * к ответу, приходящему с кросс-серверного сервера, и обманом заставит браузер разрешить прохождение запроса.

2. Используйте сторонний прокси:

Запросы, исходящие от нашего браузера, могут быть отправлены через прокси-сервер, который прикрепляет заголовок Access-Control-Allow-Origin: * к каждому ответу, который он отправляет обратно. Сервер cors-anywhere выступает в роли промежуточного прокси между клиентом и сервером.

В этом случае, если вы хотите отправить запрос на https://example.com, запрос будет отправлен на https://cors-anywhere.herokuapp.com/ вместе с информацией об исходном сервере, который вы хочу ударить. Это решение — отличный вариант использования, когда мы не хотим обременять себя каким-либо бэкенд-программированием. Мы будем использовать cors-anywhere и преобразовывать запрос (браузер-сервер) в запрос (сервер-сервер).

3. Создайте прокси-сервер.

Одной из проблем использования стороннего прокси-сервера является зависимость. Мы не можем подтвердить его доступность и масштабируемость. Мы также не можем ему полностью доверять и отправлять клиентские секреты на прокси-сервер. Лучшим подходом является создание прокси-сервера и размещение его вместе с кодовой базой внешнего интерфейса. Таким образом, запросы сначала будут направляться на наш сервер, находящийся в том же домене, а затем переадресовываться с нашего сервера на https://example.com. Это установит связь (сервер-сервер), и запрос будет выполнен.

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