2

I understand that a lot of APIs are protected using a (possibly public) API Key, to identify who is making the request, and a secret to hmac the parameters and determine if the client is actually who claims to be.

The thing is, if I'm sure the API Key is private and use https:

  1. What are the risks of not using a secret to "sign" the request?
  2. The only one that comes to my mind is a MiTM modifying the parameters, but it should not be a concern if I use HTTPS, right?
  3. Is it another layer of security just to be sure?
1

First: you cannot be sure that the API key is private and will remain private.

As soon as the device/product/application is on the real world, it can and will be broken. Don't rely on it.

And as soon as the key leaks, nothing will stop anybody to simply start sending requests, and you can't tell who is sending, or how to filter or block fraudulent requests.

Creating a secret is not hard, and you must do it. It will save you a lot of trouble along the way.

If a hacker breaks the application and gets the key and secret, you revoke access to that secret and he loses access to the API. All your other uses continue using the API without problem. Without the secret, you must create another key, and all your clients lose access.

  • But in case the client application (e.g. a web app) is broken, the hacker would have access to the secret and would be able to send requests too. What am I missing? – Sergio Aristizábal Oct 8 '14 at 19:17
  • I edited the answer. – ThoriumBR Oct 8 '14 at 19:26

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.