Archive for November, 2017

I recently had the need to think about and articulate a few things about the security characteristics of an API, and I realized that my decisions are sort of ad-hoc: I really need to write them down. While security can be bypassed by determined hackers, an API should always have some basic guards in place. So here are my principles of API security.

1. Authorized caller

An API should accept only authorized callers.

  • If it is an API with known clients, then it can secure based on IP address
  • If clients are unknown, such as a mobile app, then the API should include tokenized authentication headers constructed using an algorithm

2. User restricted

If an API is acting on behalf of a user, then the database and API should restrict itself to actions authorized for that user.

3. Server secured

An API should never depend upon a client for any security.

  • It should not depend on a client to parse a receipt to determine what products were purchased
  • It should not deliver secure data and depend on the client to know when to show or hide that data

4. Secure logging

An API should never store confidential information in a log, such as passwords, email addresses, etc… Your logging functions should filter out that information before storing it.

There are plenty of other things you can do to increase the security of an API and its data, such as encrypting certain data or implementing certificate pinning. It goes without saying that an API should sit on an SSL server, and you should never store passwords – only a hash of the password. But I feel if you follow these 4 general API security principles, your API projects will be successful, and you won’t be getting those high priority bug tickets because Bob can somehow see Joe’s data!