4

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?

datasn.io
  • 749
  • 1
  • 8
  • 9
  • 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 https://en.wikipedia.org/wiki/Cross-origin_resource_sharing – user2320464 Jun 22 '15 at 06:15
  • I am looking for a solution also. The only thing I found so far is to use encrypted signature containing window.location and timestamp, put the encryption key in JavaScript and obfuscate the code. So it will depend on the level of obfuscation obviously. I am exploring some commercial soultions – Toolkit Jun 01 '22 at 10:08
  • That's called "domain lock" btw and I am really surprised there is no some kind of SSL/browser native implementation for this. People who suggest CORS or referer need to be fired – Toolkit Jun 01 '22 at 10:50

3 Answers3

8

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 server side, so your customers might have to make some changes to their application.

AngryUbuntuNerd
  • 103
  • 2
thexacre
  • 8,444
  • 3
  • 24
  • 35
1

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.

crizCraig
  • 111
  • 3
1

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.

Paddy Steed
  • 21
  • 1
  • How can API make sure the request originated on a valid website? I still don't get how TLS can help to restrict domain – Toolkit May 29 '22 at 11:10