> In DRM, the attacker is also the recipient. It's not Alice and Bob and Carol, it's just Alice and Bob.
What applies to DRM applies to your webapp as well.
The best you can do is make this inconvenient: lock it down by IP range if you can. Make the javascript hard to reverse engineer (there are encryption tools out there). Have the API ask a question only a user would know. Password protect access to the app before you ever send javascript which accesses your web service. Do all this over SSL.
This doesn't even make it hard anymore - voluntary or not everything's a bit of an open API when you can use headless browsing to automate interacting with websites and generate legitimately constructed requests.
CAPTCHA-ish 'human authentication' for API requests would make things hard.
This is a great answer, but it's also very important to remember that the IP range you're locking down to may not be the CIDR block you think it is if there are BGP or rDNS shenanigans occurring.
I think that in my threat models "mistaken BGP entry" is not something that happens because of determined attackers, it's something that happens all the time because people is people.
See http://craphound.com/msftdrm.txt:
> In DRM, the attacker is also the recipient. It's not Alice and Bob and Carol, it's just Alice and Bob.
What applies to DRM applies to your webapp as well.
The best you can do is make this inconvenient: lock it down by IP range if you can. Make the javascript hard to reverse engineer (there are encryption tools out there). Have the API ask a question only a user would know. Password protect access to the app before you ever send javascript which accesses your web service. Do all this over SSL.