URL-based API key constraint: how does validation work?

Question

I am interested to know how the URL-based api key restriction works, for example, used by Google to protect its Google Maps service.

From what I understand from this article, “ Restricting access to Ajax services ,” there are two parts: first, when the service creates a specific key for a given domain using a one-way hash function; and second, where the service verifies the key based on the Referer header.

Although the article is understandable, I still have a problem trying to figure out how safe the verification method is. I mean, if the key is checked only against the referent, isn’t it so easy to fake? I think that a simple “127.0.0.1 www.mydomain.com” in the hosts file will be enough to trick the check, and think that the referent is www.mydomain.com.

Perhaps I misunderstood some things, and some clarifications will be appreciated.

Answer 1

The "Limitations" section of the article you are citing specifically mentions the possibility of link spoofing.

Changing the host file can really be enough to fake your referrer, but only when accessing the site from your computer. This means that you can abuse the license only during local testing. This is not a very interesting curse.

To publish your application, you need to trick the referrer into each user's browsers if you are not using the API from the local launch executable, in which case you are probably in full control of all the headers.