Why does the browser not allow CORS when server side script could easily do this?

Question

Under the same-origin policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

But I did not get the essence of it. If I cannot make a cross domain request from my browser, I will make it through my PHP script. It will work fine. Isn't it?

So, instead of doing the following:

var xhr = new XMLHttpRequest();
var url = "https://www.google.com/finance/converter?a="+amount+'&from='+from+'&to='+to;
if(xhr) {
    xhr.open('GET', url, true);
    xhr.onload = function() {
        // Handle
    };
    xhr.send();
}

which will result in :

XMLHttpRequest cannot load https://www.google.com/finance/converter?foo. No
'Access-Control-Allow-Origin' header is present on the requested
resource. Origin abc.com is therefore not allowed access.

I could do via my own php script by sending a ajax request like:

$.ajax({
    method: "GET",
    url: "./bin/http/CimmClient.php",
    dataType: 'html',
    data:{
        a: amount,
        from: from,
        to: to
    }       
})
.done(function(data, textStatus, jqXHR ){
  // Handle
})

And this works perfectly fine. PHP only sends an HTTP request to another domain and then sends back the response to javascript.

So, what in principle was the difference? Why does the browser prevent sending cross domain HTTP request, when php/java/others would easily allow this?

it's called "security" and "intellectual property" - if a remote site ALLOWS you to access their resources from a browser, they will issue CORS headers in the response as appropriate ... or if they're stuck in the past, they may have JSONP as a way to use their resources — Jaromanda X, Feb 10 '16 at 08:22
if you want currency conversion specifically, there are API's available to you, you just have to do some research — Jaromanda X, Feb 10 '16 at 08:29
@JaromandaX Why the same theory doesn't apply when sending a request via `php`? — Suhail Gupta, Feb 10 '16 at 08:34
You need to add a header in server to allow that. Check this answer, it explains this: http://stackoverflow.com/a/10636765/5906538 Hope this help you :) — pucheta, Feb 10 '16 at 08:23
good question. CORS is a complex subject. Browsers used to have no constraints with cross origin requests ... which made all sorts of nasty pages possible that stole your banking passwords etc ... cross origin restrictions in browsers made that less possible, but that meant that genuine remote access harder/impossible. CORS simply allows the source server to control access. Access using PHP etc isn't identical to how a browser accesses a site, and a properly written site does not suffer security issues if someone tries to use a PHP middleman to gain illicit access — Jaromanda X, Feb 10 '16 at 08:45
"The other answer there, doesn't tell the real implementation" — Yes it does. — Quentin, Feb 10 '16 at 08:58
"How the request made from a browser is different from a request made by php? " — Nothing (significant) is different about the request (other than the cookies, the ip address it comes from, etc). As the highest voted answer says, it is the **browser** that denies JavaScript access to the response. — Quentin, Feb 10 '16 at 08:58
@Quentin I understand the point. I earlier made a wrong assumption. — Suhail Gupta, Feb 10 '16 at 10:34

Wapac · Answer 1 · 2016-02-10T08:42:03.223

These limitations are not implement to prevent YOU to use any kind of service, these are implemented in order to prevent a malicious code that you are not aware of to act ON YOUR BEHALF.

So, if YOU WANT to, you can obtain the data - e.g. using server side script, and that is OK. But if you load a malicious web page to your browser, or a web page that was infected by malware, its scripts are not able to act on your behalf and send requests to third party services.

It could be argued that there are legitimate use cases for such cross origin access, but the security on the Internet is a big thing and it is considered before comfort of developers.

For example, assume you have an online bank that uses cookies to store information on users' opened authenticated sessions. You log into a bank and check your accounts. You leave this tab open in your browser and you access a malicious website. That website sends Ajax to the bank asking for a list of transactions using a simple GET request. Your browser will invoke the GET request and send session cookies to the bank and the bank will reply with a sensitive information about your accounts. The malicious script then uploads the data to its server. Once the cross origin access is forbidden, this scenario is no longer possible.

if there is a malicious script on page and it wants to act on behalf of me, it has nothing to do with CORS, maybe CSRF, but not CORS. so the malicious script just reads the cookies and sent them to his own server with Allow-Access-Control-Policy set to *. and that works just fine, and CORS had nothing to do with that. please see https://stackoverflow.com/questions/71294134/how-exactly-cors-is-improving-security — behz4d, Feb 28 '22 at 11:18

Why does the browser not allow CORS when server side script could easily do this?

1 Answers1