I need to create a webservice providing javascript widgets and ajax calls, which only run on certain domains. After doing a lot of research, I only came up with a combination of HTTP-Referer and API Keys, which is pretty easy to break with tools like RefControl, or am I missing something? Are there more secure solutions for this problem?
A:
REFERER and API keys are indeed pretty much the only way to go, seeing as it's the user's browser making the request and not the server.
You do not need tools like RefControl, however: Those would allow a single user to make an unwanted request to your widget, but it won't make a person running a site able to use the widget.
Pekka
2010-08-27 08:43:52
Unfortunately this single user misusing the widget is the case I need to be prepared for. I'll need to find a way to detect misuse at least after it happens.Thanks for the reply anyways!
Philipp
2010-08-27 08:58:24
@Philipp you're welcome. But why do you need to be prepared for a *single user* viewing your widget? If you are serving paid content, you won't get around some kind of password protection. Maybe you should elaborate more about your situation.
Pekka
2010-08-27 09:11:50
@Pekka: It's not paid content, but if a user starts to simulate execution of widgets on different sites (and the application may motivate some people to do this), the integrity and credibility of the whole service may suffer.Token based restrictions would work better, but requires server-side code from the integrating sites, which makes it a little more complicated for them. And - who would have guessed - integration has to be a no-brainer.
Philipp
2010-08-27 09:24:59
@Philipp I think you are misunderstanding this. A single user can falsify the referer header to get the widget *in their browser only*. I don't see how something like that can be a problem?
Pekka
2010-08-27 09:29:18
Perhaps I'm really misunderstanding it, which would be great, since this would reduce my problem-count by one.A user could collect API keys and domains from various sites using this service and fake widget-calls without really visiting them. And thinking bigger, this could be completely automated and handed over to other users who want to do the same.
Philipp
2010-08-27 09:48:57
@Philipp well, yes, *that* could always be done. I don't think you will not be able to prevent that without some sort of authentication - and maybe not even then, seeing as a user could hand the credential over to other users. Also, I could be taking screen shots of your widget, and post those on my site - also something you can't prevent using technical means. If you want useful input on this, you need to expand about why all this would be a problem.
Pekka
2010-08-27 09:58:51
@Pekka: Actually "seeing" the widget triggers a benefit in the users webservice-account. Not monetary, but ideally, which may be enough to make people try to break it. Passing credentials doesn't help people to get this benefits for their account, neither do screenshots. But if somebody scans sites for API Keys, he may fake widget execution, and provide other users with the benefit, circumventing the purpose of the system.
Philipp
2010-08-27 10:11:24
@Philip ah, I see. I don't see a way for you to prevent this. However, you can threaten to monitor the IP address(es) the views are coming from, and block the account on any suspicious activity (e.g. repeated views coming from the same IP address or session). Ad providers like Google have the exact same problem.
Pekka
2010-08-27 10:15:37
@Pekka: I was afraid we would end up like this ... But I think monitoring the intervals already gives me a good hint on somebody misusing it. Thanks a lot for your patience!
Philipp
2010-08-27 10:44:03
@Philipp you're welcome.
Pekka
2010-08-27 10:46:24