When authenticating from a browser application to an API layer, you can verify the request origin for CORS requests. I'm aware that this is primarily to prevent CSRF attacks. It doesn't prevent an attacker from accessing the endpoint themselves, but it does prevent the attacker from hijacking an unsuspecting user's browser from hitting the endpoint unknowingly with an AJAX request, when the user is on a domain under the attacker's control.

My question is, is there any benefit in verifying the request origin when implementing an API-to-API communication? For instance, let's say two APIs are built to transact requests between each other, using a shared secret (for simplicity's sake, an API key -- but, depending on access needs, a more advanced approach like OAuth might be applicable). In addition to verifying the API key, should the server also check the request's host to confirm that it originated from a trusted API server? Or is a request host easily spoofable (since the request would be coming from another server with complete control of the headers it sends in the HTTP request) and thus such a check would be pointless?

  • 2
    Pointless, as you pointed out. Commented Dec 10, 2017 at 20:55

1 Answer 1


Verifying the hostname does not provide you with any extra guarantee of authenticity. Assuming that, in addition to using a shared secret, the APIs are able to verify each other's private keys, then you get a pretty strong guarantee that they are who they say they are. Anyone who is able to steal said private keys to fully impersonate one of the hosts will be able to trivially alter the hostname.

You must log in to answer this question.

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