В чем проблема, которую решит CORS?

Ответ 1

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

Это ограничение существует, потому что запросы, сделанные в других доменах вашим браузером, будут содержать ваши файлы cookie, что часто означает, что вы вошли бы на другой сайт. Таким образом, без такого же происхождения на каком-либо сайте мог размещаться JavaScript, который вызывал logout на stackoverflow.com, например, и он выходил из системы. Теперь представьте себе осложнения, когда мы говорим о социальных сетях, банковских сайтах и ​​т.д.

Таким образом, все браузеры просто ограничивают сетевые вызовы на основе script в своем собственном домене, чтобы сделать его простым и безопасным.

Сайт X на www.x.com не может делать запросы AJAX на сайт Y на www.y.com, только на *.x.com

Существуют некоторые известные методы работы (такие как JSONP, которые не содержат файлы cookie в запросе), но это не постоянное решение.

CORS позволяет выполнять эти междоменные запросы, но только тогда, когда каждая сторона выбирает поддержку CORS.

Ответ 2

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

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

Например, предположим, что я случайно загружаю http://evil.com/, который отправляет запрос для http://mail.google.com/. Если SOP не был на месте, и я был подписан в Gmail, script at evil.com мог видеть мой почтовый ящик. Если сайт evil.com хочет загрузить mail.google.com без моих файлов cookie, он может просто использовать прокси-сервер; публичное содержимое mail.google.com не является секретом (но содержимое mail.google.com при доступе к моим куки файлам является секретом).

(Обратите внимание, что я сказал "контент с ограниченным доступом", но также может быть контент с ограниченным топологией, когда веб-сайт доступен только для определенных IP-адресов.)

Иногда, однако, не evil.com пытается заглянуть в ваш почтовый ящик. Иногда это просто полезный веб-сайт (скажем, http://goodsite.foo), пытающийся использовать открытый API из другого источника (скажем, http://api.example.com). Программисты, которые упорно работали над api.example.com хотят, чтобы все корни, чтобы получить доступ к их содержанию сайта свободно. В этом случае сервер API в api.example.com может использовать заголовки CORS, чтобы позволить goodsite.foo (или любому другому запрашивающему началу) получить доступ к своим ответам API.

Итак, в общем случае мы предполагаем, что по умолчанию доступ к перекрестному соединению является плохим (подумайте о том, что кто-то пытается прочитать ваш почтовый ящик), но бывают случаи, когда это хорошо (подумайте о веб-сайте, пытающемся получить доступ к открытый API). CORS позволяет сделать хороший случай, когда запрашиваемый сайт хочет, чтобы это произошло.

Ответ 3

Есть причины безопасности и неприкосновенности для того, чтобы не разрешать запросы из любого места. Если вы посетили мой сайт, вы бы не захотели, чтобы мой код отправлял запросы в Facebook, reddit, ваш банк, eBay и т.д. Из вашего браузера, используя ваши файлы cookie, верно? Мой сайт будет иметь возможность делать сообщения, читать информацию, размещать заказы и т.д. От вашего имени. Или от моего имени с вашими учетными записями.