I've got a simple ASP MVC 6 WebAPI I'm currently working on in which registered users can call request data using a sample of the URL below:


b8pE5Qodiw refers to the unique API code for a confirmed user. This is generated by the application and the user is not able to use it until they confirm their email.

I'm generating the code following the answer on this SO question

From a security standpoint, are their potential issues with having the user API code in the URL and how I'm generating the API code?

Is there a best practice of how RESTful services generate API URL's

  • 1
    depends on the "user". Secured APIs typically provide services for customers of paying customers, and leaking the secret could keep your user from making money. if your users don't republish the secret, then it's probably fine. POST would keep it out of http logs, which is a win, but what you describe is common practice. Better would be to use a one-time token that maps to the static userID for the session. – dandavis Dec 7 '16 at 16:50
  • 1
    You can make API code twice as long for increased entropy, and why not use cookies? This makes it easier to run stats on the web logs without revealing sessionid via URLs – Aria Dec 7 '16 at 17:12

There's one pretty major issue that's immediately apparent, but may be an artifact of your development environment: the request is transmitted over plain ol' http, which means the API key is available to anyone performing a man-in-the-middle attack.

The solution for this, of course, is to only ever make these sorts of requests over https. You can't control what your users do (after all, they could just publish their key on the web), but you can strongly encourage this behaviour. Possible ways to do this include:

  • ensuring all your examples use https
  • big fat warnings in the documentation
  • returning an error page, rather than a redirect, when an API request is sent over http
  • enabling hsts for your domain (although I don't think this will have any effect on custom curl-based programs)

As mentioned in comments, moving the key into the request body will prevent it from showing up in your access logs, which may be treated with less security rigor than your database.

Personally, your keys seem too short to me. They're used by programs, not humans, so there's no reason not to have a much longer key length that's far beyond what you might imagine to be guessable (remember that an attacker doesn't need to guess a specific key, but just any that is valid).

| improve this answer | |
  • note that HTTPS protects the key in GET as well, so no need to move to POST in that case. – dandavis Dec 7 '16 at 17:40
  • They're different things. Using POST instead of GET is ineffectual in protecting the key from a MitM, as it's still viewable as part of the request; what it does protect against is getting included in your server logs, which won't be affected by HTTPS. – Xiong Chiamiov Dec 7 '16 at 20:11
  • yes, i forgot what url issue we were talking about, thanks for clarifying. – dandavis Dec 7 '16 at 21:45

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.