When doing a cross domain HTTP request from a Javascript client, like JQuery (from a client browser). In the receiving end, will it be able to point out where the Javascript request came from?
Example, I have a site, and it loads up a Javascript that will call a web service, say foo.com/someapi
When the API receives the request, what will it be able to get the origination host. Say my site is bar.com and when I access bar.com/index.html it will load up the page and fire up the javascript HTTP request to foo.com/someapi
In the client request there was no server side request involved its pure Javascript.
Furthermore, what if the call is executed from a development environment, like localhost what will be the hostname that the receiving foo.com/someapi will get?
What does a browser do when doing HTTP request from Javascript:
- In a public domain site
- And with a localhost site
@Andbdrew mentions the Origin header, which is part of the Cross-Origin Resource Sharing (CORS) specification. It's a useful guide, but not necessarily accurate (or always available).
The only bit of information that is (almost) 100% reliable is the IP address that the request came from (or, rather the IP address of the closest proxy server that relayed the request). That needs to be accurate or else the response will not get back to the computer that made the request. However, it only shows the location of the client, and not the origin of the page that is making the request. (And this location will be the same, regardless of whether the page was loaded from file, localhost, or an external site)
With a CORS-supporting browser, what is supposed to happen is this:
Client requests a page from foo.com
foo.com returns a page, including some scripts (possibly as external resources).
These scripts run with their origin set to foo.com
The scripts try to request another resource from bar.com
The client sends a request to bar.com with the HTTP Origin header set to 'foo.com' -- this isn't the client's hostname, but it represents where the scripts came from.
bar.com (if it supports CORS) should return the resource with an Access-Control-Allow-Origin header set (or a related header)
A couple of points:
If the client does not support CORS, then it will not send the Origin header at all. See http://caniuse.com/cors for a browser support matrix.
If the first request is not to foo.com, but to a file:// url, then no Origin header will be sent.
If that request is not a file:// url, but instead comes from localhost, then the Origin header should be set. There's nothing in the spec which says not to, but I haven't checked to see what browsers actually do.
There are some other situations in which the Origin header will not be sent; browser extensions and (I believe) Chrome apps will not send it.
If the server does not support CORS, then it will ignore the header, and the browser will probably reject the response.
Now, with all of that being said, you can't rely on any of this. CORS is fundamentally a technology designed to help the client browser protect itself against the scripts that it runs. It is not about protecting the server, or even letting the server know who is accessing the data, since it could be very easily faked. The reason it exists is to give "good" scripts running in a "good" browser a way of saying who they are -- a way that "bad" scripts running in the same "good' browser should not be able to impersonate.
It absolutely does not mean that the server which actually controls the resource should rely on that header for any sort of security. If the data being accessed is really important, there should be proper access controls on it (https, passwords, and secure cookie-based sessions are a good combination)
If your site is bar.com, the ORIGIN header will be set to bar.com.
You can check this out in the NET tab of your browser's inspector.
EDIT: If you are coming from your dev environment or localhost, you should set up your host file (assuming linux / mac) and alias local.bar.com to 127.0.0.1. Then, the ORIGIN header will be set to local.bar.com.
This header should not be mistaken for an authentication strategy. To try and limit access to authorized users, you could look into OAuth at http://oauth.net/2/
