RestQL (REST) MCe
Security FIRST, users and leaked keys

What's the concern?

  • Before you do anything else – you need to consider security.
  • The MCe API gives you access to the entire system; edit, delete, read.
  • The User plus API Key associated with the user is your security.
  • We have done it simply on purpose to make it as easy as possible for you to achieve high security.

Best Practices

Here are our recommended best practices:

  1. For an API key, create a special purpose user , that all it is used for is API calls.
    1. Name the user with your name, because when you leave the company or move into another department, you want the new people to delete you so you can't be blamed for damage.
    2. Name the user ALSO with something about the purpose. If you are going to access all API keys, then maybe the user just is "<yourname> API access", for example "Peter Horwood API" or if you are in for a specific purpose, or you want to create 2 or more users for different API purposes, you might have it as "<yourname> Financial API" example "Peter Horwood Financial API"
  2. Keep the API key very secure. Keep it where you keep your most important passwords and other type secrets.
  3. When you are leaving the company/position, if at all possible and assuming you are leaving on good terms, as part of your hand-off to the new person(s), delete these special purpose users, and YOU do NOT obtain the new API keys, that is the responsibility of the new person. This is to protect you. So you can't be accused of having kept copies of the keys somewhere and used them – because even if you have copies of the keys, they have no value once the user is deleted.
  4. If you are taking over for someone, make sure their users are deleted, that way they cannot use keys that they copied to access or damage your data, this is for the company's protection.
  5. If you find out that, despite your precautions, the API keys have been leaked, delete the user(s) associated with the leak and create new users for the new keys.

As summary thoughts:

  • The USER plus the KEY is security. If you are missing either piece, access is secure.
  • If the user leaves – delete the user
  • If the key is leaked - delete the user
  • Create special purpose users as needed, so the "delete the user" is a mundane instruction.
  • The simpler security is, typically the more secure it is. The more complex security is, often the more leaks and opportunities there are to bypass security. We have purposed made it very simple for you to have very high level of security if you follow our best practices.