2

I'm opening up some API access to my site and my users are required to specify from which of their websites, such as example.com, they will make the API requests.

I'm wondering if there's any way to verify that an HTTP request is indeed from a specific domain so I can make the user / domain accountable?

  • Maybe you can check the referer. If your users integrate calls to your api on their website front-end (visitors browsers) i dont know any way (js or else) to fake it (if you dont have an XSS vulnerability on your side of course). – r00t Jun 21 '15 at 16:43
  • 1
    What platform are you using? There's CORS en.wikipedia.org/wiki/Cross-origin_resource_sharing – user2320464 Jun 22 '15 at 6:15
5

I'm assuming what you mean is that visitors to another site will make client side requests to your API, and you want to attribute these requests to that site.

There are several ways to go about this depending on how strong you need the authentication to be.

If you're just using the data for statistical purposes and maybe to stop unauthorized use from very unsophisticated attackers then you can use the HTTP referrer. This can of course be forged, so this won't be suitable if you require very strong authentication.

Another option is to use an API key / site ID that is passed along with all requests. An attacker could easily take the API key from one customer and abuse it, or use it on another site - but at least you can reissue the key/ID if it's abused unlike the referrer.

If you need very strong authentication then you'll have to have your customers generate a time limited signed token on the server side which the user then passes in their request to you. Basically, each customer would have a secret key on the server side and they'd use that to encrypt a message including a time limit - you can check that by decrypting it when the user passes it to you. You might be able to leverage something like http://jwt.io/ to do this. The disadvantage of this is that you can't do this completely on the client side, so your customers might have to make some changes to their application.

0

The most complete solution would be to use TLS with client certificates. This allows the server to verify the identity of the client. Any other solution such as JWT's or some custom signature scheme is likely to be wildly insecure. TLS does all the hard work for you. If you are particularly worried about CA compromises, then you could set yourself up as a CA and then only add yourself to the trusted pool.

0

I'm doing this via a confirmation POST request back to the domain with a one time secret key.

i.e.

POST request from what's supposed to be example.com to

https://yourapi.com?one-time-key=1234678901234567890deadbeef


You respond with a confirmation POST to example.com, verifying the key:

https://example.com/confirm?one-time-key=1234678901234567890deadbeef

example.com then deletes the key and sends back status code 100 continue.


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.