I'm working on a small web service that provides some functionality that can be embedded in a web page with an iframe. As this is a subscription-based service, I'd like to be able to manage who can and cannot access the functionality in question via API keys.

My understanding is that one popular approach is to embed an API key into the resource, e.g.:

<iframe src='http://service.com/API_KEY_GOES_HERE/' height='750' width='640'>

When the server receives a request from client, it does a lookup on the referrer to ensure that the site requesting the resource is allowed to access it.

My question is as follows: can't referres be spoofed and wouldn't this make it trivial to circumvent this system? What am I missing?


Referrers can be spoofed, but only by the user-agent. Another website embedding an iframe with the API key wouldn't be able to control the referrer of its users. So if your goal is to prevent sites from being able to clone API keys, then the referrer check will generally work.

Keep in mind that the referrer is not sent if going https -> http, and some users might have browsers set not to send the referrer.

  • Ok, that makes more sense! What do you mean by "going https -> http"? How should I handle cases where referrers aren't sent? – blz Jun 23 '14 at 11:55
  • If the source page is https, but your iframe is http, the referrer won't be sent. (And users will get a mixed-content warning.) Depending on what your API is used for, dropping requests without a referrer might be an option, the proportion of people blocking referrer headers is pretty small. – David Jun 23 '14 at 14:21
  • Ok, now it all makes sense. Thank you very much for your answer! – blz Jun 23 '14 at 17:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.