API Security

A friend and colleague recently asked for an overview of the relevant language of “API security”. Here was my reply:

---

First off, API security is a very messy topic, so I am quite curious how you & others are parsing + thinking about it.

Briefly though: API security is much broader than just web API security (though that may be your interest) since it also includes OS APIs, language/library APIs, as well as APIs used over nominally private transports.

That said, IMO, the usual major decomposition is into

• authentication,
• authorization,
• the access control to implement them,
• key distribution + recovery protocols,
• logging + log usability,
• LANGSEC concerns (gadgets, injections, chimaeras),
• confused deputies,
• insider monitoring, and
• systems + implementation abusability considerations like
  • DoS-protection,
  • cache purgeability, and
  • harassment/doxxing/accessory hazards — just to start.

There is a fairly long reading list behind the above outline. However, to simplify, I like to say that:

• authentication is about agreeing on who said what,
• authorization is about deciding how to act on what was said,
• key distribution + recovery is very system-specific,
• logging should be searchable, machine-readable, and retained a long time,
• the LANGSEC stuff is just tricky and mostly needs to be brute-forced – i.e. by requiring safe languages / libraries / etc. since normal humans cannot avoid these issues unaided.
• capabilities probably are the right solution for deputies but are too hard to understand (maybe should have been called “caller allocates [access]”),
• insider monitoring = squeaky floor boards + N-party control + delays for reaction time + vetos for coercion?, and
• the systems-stuff is mostly either situation specific details or rules-of-thumb like:
  • “caches must be purgeable”,
  • “storage will store bad stuff”,
  • “compute will be mined”,
  • “you need a bigger pipe than the adversary”,
  • “users will stalk + harass each other with all available means”,
  • “backups will fail unless they are frequently restored from + end-to-end verified”, etc.