Getting the domain that calls an PHP file on your server through AJAX

Question

I\'m building out an API and have a question about how to track/know which domains use the call.

The API call is built in PHP, and doesn\'t require any authenticatio

Answer 1

"I would think that the referer would be metromapper.org, since that domain calls the yourmapper.com script after it loads"

That's incorrect actually. Firstly you should never rely on the HTTP_REFERER because it's a voluntary parameter passed by most (not all) browsers, and it can easily be spoofed. I can send your website requests using CURL that make it look like the referrer was whitehouse.gov if I want to. There's no security measures in place there.

That being said. The browser sets that parameter to the page that referred the user to the currently loaded page. Not script. So the reason you see the result you're seeing is because the user was referred to metromapper.org by a link on stackoverflow.com

Finally, let's get to the juicy part. You're using JS to code things in the browser. That's fine and there's absolutely no problem with that. But you have to remember that JS is open source. So people can (and will) mess with your code to play with your API just because they can. That being said. Your best bet is probably to pass the url of the site along with the request in your JS api. That's the best way to "track" what sites are using your script. You could check server side to make sure that a URL was passed. That would prevent people from modifying your API to remove the bit that sends their URL to your server. It won't, however, prevent them from modifying it to use someone else's url or a random unregistered one as the parameter.

Sure you could build a PHP API that they run on their server. The JS API connects to the PHP API and the PHP API is zend-guard encoded (or some other source protection code system) but then there's still going to be people who decode the file to get back to your source and mess with you. Granted there'd be far less people able to do that, and the average user would just rather use your API as it is. Then you also have the issue of people not being able to run your API on servers that don't have the ability to run encoded PHP files.

In the end you have to determine your level of desired security and authentication, but since your API is running in JavaScript in the client browser, there is very little available beyond obfuscation.

I'd say your best option would be to simply have your JS code snag the URL of the current page and send it with the API request. From there your server can process the URL to get the root domain and any other info you want to store.

If you want to prevent people from "spoofing" requests for other user's website urls, you could implement a PHP API that gets installed on the user's server at a certain place. For example http://www.domain.com/my-app-name.php

All JS API calls should go through that script. When the user downloads your API they should enter their website URL and some other info. Your system generates a "key" and injects it into the script before packaging it for them to download. That key is valid for their domain and used to encode all transmission to/from your API using say blowfish or another 2-way encryption algorithm. This way when your API receives a request from their PHP API file, you're getting the url of the page that request was made from, encoded with a key that only you and the admin of that site have. So the request comes through as something like this: metromapper.org/api?site=[url_encoded_page_address]&req=[encrypted_request]

Your server uses the page url to determine what key should be used to decrypt the data. It then decrypts the data. If the data is corrupted or doesn't decrypt into what you expect, then it's an invalid request and you should just exit returning nothing.

The reason I suggest using a PHP file for encryption as opposed to writing the encryption into JS is because you don't want to burden the client (each site visitor) with the load of encryption/decryption and PHP is going to handle it much faster than JS would since there are libraries made to handle those tasks for you.

At any rate that should get you on the right track to being able to keep track of and validate requests for different sites against your API.

Answer 2

You could generate a hash based on the domain name, and let the users of your API send the domain name and the hash in each request. Now since you're API uses PHP you'll have set the 'Access-Control-Allow-Origin' somewhere in the header. If you do this in PHP you can play around with that a bit. The script below is a simple example of an implementation that doesn't require php on the caller side (domain that uses you're API).

Caller Side (no php required):

<script type="text/javascript">
  function callA() {
    var xhttp = new XMLHttpRequest();
    xhttp.open("GET", "//ajaxdomain.com/call.php?"+
                      "dom=www.callerdomain.com&"+
                      "key=41f8201df6cf1322cc192025cc6c5013",
               true);
    xhttp.onreadystatechange = function() {
      if(xhttp.readyState == 4 && xhttp.status == 200) {
        handleResponse(xhttp.responseText);
      }
    }
    xhttp.send();
  }
</script>

Ajax Server Side (PHP):

<?php
  if($_GET['key']==md5($_GET['dom']."Salt")) {
    header("Access-Control-Allow-Origin: http://".$_GET['dom']);
  }
?>

This way the header would also be placed if the call came from a malicious domain, but rest will bounce because of a Cross Origin Exception, and thus no result will be given.

For the sake code space I used a md5 hash in this example, but you could use more complex hashes if you want. Note that you should (as always) keep the used salt secret.

I put a working example online at the following (sub)domains. The pages are identical.

cors1.serioushare.com - Only works on 'CORS 1' button.
cors2.serioushare.com - Only works on 'CORS 2' button.