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, 2015 at 16:43
  • 1
    What platform are you using? There's CORS en.wikipedia.org/wiki/Cross-origin_resource_sharing Jun 22, 2015 at 6: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 1, 2022 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 1, 2022 at 10:50
  • @Toolkit Just in case some client's API key and secret gets compromised, I want to have additional check to make sure that my backend service only accepts request for generating tokens from a particular domain. I don't want anyone to be able to generate tokens. How can I achieve this? Mar 2, 2023 at 9:43

3 Answers 3


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.


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.

  • 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, 2022 at 11:10

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


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


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


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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .