

Ask HN: How do you secure a client side (JavaScript) API? - bgdam

Ok, so here&#x27;s the background. I am working on a widget, which can be plugged into any website add some functionality to it. In order to authenticate against the API, I provide an client token, and a secret.<p>When the client widget authenticates it passes a client generated challenge string, the client token, and a hash which is calculated as hash(challenge+secret). Everything except the secret is available to the client.<p>This scheme is currently vulnerable to copying the challenge string, client token and hash and then reused on any other site. Currently, the only solution I can think of to resolve this is to use short lived (say 20 mins) server generated challenge strings and use those to generate a hash.thus only the client token and hash would be available to the client and that will only be valid for about 20 mins or so.<p>Is there any better way to do this?
======
davismwfl
I hope I am understanding properly, please let me know otherwise.

Off the top of my head, one option would be to embed the domain name into the
hash so that you can validate it is from the domain that is authorized to use
the token. If it comes from any others send back an error. You might have to
provide a mechanism for people to test on localhost or on development/staging
domains but that seems minor overall.

~~~
bgdam
How would I get the domain name from which the request originates? Referrer
info can be easily spoofed on HTTP, and HTTPS does not forward referrer
information at all.

Without being able to verify that the request is originating from the domain
that is specified in the hash, it is still susceptible to the same attack. The
hash, challenge and token are all still available client-side.

Basically the hash might say that it is from abc.com, but it could really be
from any domain. So yes while the token might match the hash, if both the
token and hash are copied it does not help.

~~~
davismwfl
True, I should have thought through that a little more. The domain could be
spoofed, making it less than secure and leaving you open to the same issue.

For what it is worth, on our client accessible API, we require clients to
authenticate and then send in the token we return through the http header for
each request, and the token is reset often. The token is a hash of a few
client identifiers, but it is calculated and sent to the client so the client
never calculates it. We only allow https for the API. This seems to be a
fairly common pattern.

EDIT: add link

This method is similar to how we calculate our token:

[http://billpatrianakos.me/blog/2013/09/12/securing-api-
keys-...](http://billpatrianakos.me/blog/2013/09/12/securing-api-keys-in-a-
client-side-javascript-app/)

