10

I have noticed that some API have you pass an API key as a url parameter while others have you pass it in the HTTP HEADER. I am developing a web-based application that is going to rely heavily on a REST API and right now I am just having it so the API KEY is pass through as a url parameter.

My question is whether or not one of those options is more secure than the other?

ryanzec
  • 27,284
  • 38
  • 112
  • 169
  • 1
    Does this answer your question? [Is an HTTPS query string secure?](https://stackoverflow.com/questions/323200/is-an-https-query-string-secure) – Michael Freidgeim Aug 14 '20 at 22:22

1 Answers1

8

In both cases, the API key will be passed unencrypted. So both are insecure unless you use HTTPS.

In practice, HTTP header turns out to be a little bit more secure because -

  1. The url gets stored in browser history
  2. The url gets stored in access logs on the server side

Aside : A REST API over the web cannot be secured unless you ask the user to login with his credentials. Anybody can easily identify the API key and make requests to your server.

EDIT : In response to @segfault's comments -

A website user generally does not enter an API key. They enter their user name and password, and this is traded to get the API key or access token as it is typically called.

If you force your users to enter the API key instead of user name and password, well, it'd be secure. But as I said, I haven't seen any serious application do that.

More specifically, I meant "If a backend API expects an API key, and you are making AJAX calls from the browser, and you don't ask the user for some sort of credentials, you are insecure"

Sripathi Krishnan
  • 30,948
  • 4
  • 76
  • 83
  • Never thought about that minor benefits of making it part of the HTTP HEADER, guess I will do that. On the aside, that is only true if it is HTTP, if the API runs on HTTPS, it is not as easy to identify and steal and API key. – ryanzec Mar 07 '12 at 16:38
  • @ryanzec : re. aside - I can just inspect the communication in firebug and extract the API key, even if you use HTTPS. You really cannot secure a REST API with just an API key. – Sripathi Krishnan Mar 08 '12 at 06:48
  • Sorry but the aside is just wrong. the user who "extracts the api key with firebug" is the authorized user! That is the same person who would know his password if you required the user to login.... – Segfault Feb 11 '13 at 16:11
  • 2
    Sri, there are many problems with even your updated and amended aside. You haven't seen any serious application accept api keys instead of passwords? ALL serious applications do this. Amazon web services, for example. There is nothing magically "more secure" about using a username/password to authenticate instead of an API key, in the end they are both a string of characters secret to the authorized user. – Segfault Feb 13 '13 at 20:57
  • @Segfault - There is no difference between apikeys and username/passwords. My whole point was without forcing the user to enter *some* credentials - be it username/password or API key, you cannot have a secure REST API. I only emphasized on username/password because it is atypical for a user to enter API keys. – Sripathi Krishnan Feb 13 '13 at 21:18