Почему API браузера ограничивают междоменные запросы?

если я посетить вредоносный веб-сайт, я хочу быть уверен, что :

1. он не может читать мои персональный данные с других веб-сайтов, которые я использую. Думай attacker.com чтение gmail.com
2. он не может выполнить действия от моего имени на других сайтах, которые я использую. Думай attacker.com перевод средств с моего счета на bank.com

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

та же политика происхождения в целом соответствует следующим правилам -

• Правило 1: не позволяет читать что-либо из другого домена
• Правило 2: позволяет записывать все, что вы хотите, в другой домен, но Правило № 1 не позволит вам прочитать ответ.
• Правило 3: Вы можете свободно делать междоменные запросы GET и POST запросы, но вы не можете управлять заголовками HTTP

давайте посмотрим, как различные вещи, которые вы перечислили, соответствуют вышеуказанным правилам:

1. <img> теги позволяют сделать HTTP-запрос, но нет никакого способа прочитать содержимое изображения, кроме как просто отобразить его. Например, если я сделаю это <img src="http://bank.com/get/latest/funds"/>, запрос будет выполнен (Правило 2). Но злоумышленник не может увидеть мой баланс (правило 1).

2. <script> теги работают в основном как <img>. Если вы делаете что-то вроде <script src="http://bank.com/get/latest/funds"> запрос пойдет через. Браузер также попытается проанализировать ответ как JavaScript и потерпит неудачу.

3. есть известная злоупотребления <script> теги, называемые JSONP, где вы вступаете в сговор с междоменным сервером, чтобы вы могли "читать" междоменные. Но без явного участия междоменного сервера невозможно прочитать ответ через <script> tag

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

5. <iframe> по существу новое окно браузера. Вы не можете прочитать HTML междоменного iframe. Кстати, вы можете изменить URL-адрес междоменного iframe, но вы не можете прочитать URL-адрес. Обратите внимание, как это следует двум правилам, упомянутым выше.

6. XMLHttpRequest является наиболее универсальным методом для выполнения HTTP-запросов. Это полностью находится под контролем разработчиков; браузер ничего не делает с ответом. Например, в случае <img>, <script> или <link>, браузер принимает определенный формат и в целом будет проверять его соответствующим образом. Но в XHR нет предписанного формата ответа. Таким образом, браузеры применяют ту же политику origin и предотвращают от чтения ответа, если веб-сайт кросс-домена явно не позволяет вам.

7. шрифты через font-face - это аномалия. AFAIK, только Firefox требует выбора в поведении; другие браузеры позволяют использовать шрифты так же, как вы бы использовать изображения.

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

редактировать: почему я не могу обойти все это с помощью серверного прокси?

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

серверный прокси-сервер не может получить доступ ни к cookies, ни к основным учетным данным auth. И так, даже если он может сделать запрос, сервер не будет возвращать пользовательские данные.