0

Please forgive me if this is dumb, not my field.

Say I would like to provide an API for my users like this :

www.mydomain.com/USER-API-KEY/some-user-data

Where the USER-API-KEY is 16 characters and numbers unique ID per user, known only to him.

Say the user use this to write data to a server (Amazon/Firebase, etc).

Why is this API considered to be not safe ? is there a way to make this API more safe from attacks by keeping this simplicity ?

Curnelious
  • 1
  • 16
  • 76
  • 150
  • 1
    Provided you are using HTTPS, and provided the user will not type that into their browser address bar so that it's saved in their history, [that should be okay](https://stackoverflow.com/q/499591/11683). Otherwise, if you don't mind giving up the simplicity after all, see e.g. https://stackoverflow.com/q/9386930/11683 or https://stackoverflow.com/q/5472668/11683. – GSerg Nov 17 '18 at 10:22
  • 1
    Possible duplicate of [Passing API Keys In HEADER or URL?](https://stackoverflow.com/questions/9600495/passing-api-keys-in-header-or-url) – redben Nov 17 '18 at 10:38
  • @GSerg thanks! you helped me a lot. So as long as it's https, assuming its safe enough, why API's are usually too complex with multiple keys and secrets, etc ? – Curnelious Nov 17 '18 at 10:43
  • What if some developer would like to send a POST request using this link when someone click a button on a website ? then he have to embed the link in his html and I can "view source" of his website and expose the link ? – Curnelious Nov 17 '18 at 10:51
  • Of course. But as I understand the idea is that only the person who successfully navigated to `www.mydomain.com/USER-API-KEY/` will be served that kind of HTML, at which point it's not a disclosure. – GSerg Nov 17 '18 at 13:56

1 Answers1

1

What risks you take entirely depend on you. Passing sensitive information (like an access token or api key) in the URL has its risks, but you can decide to accept those risks.

A few things that come to mind:

  • URLs get logged. They get logged on intermediate proxies, and they also get logged on the server that actually serves your API. It may be possible for an attacker to gain access to those logs, compromising API keys.

  • Not really security-related, but a change in the API key will in your scheme invalidate all cached results, which may have a potential effect on performance if keys change often (as they should, especially if you're sending them in the URL).

  • Some of your clients may have explicit policies against sending sensitive data in the URL. This means the risk in your solution is not only technical, it also has a "client relationship side" if you like.

So in short the security best practice is not to send API keys like that. If you do so, it will likely be found in a later penetration test as a vulnerability.

You can still decide to do so, and quite honestly, this is probably not how (if ever) your application will be hacked. But accepting this risk should be an informed decision.

Gabor Lengyel
  • 14,129
  • 4
  • 32
  • 59