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
That said, IMO, the usual major decomposition is into
- 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
- 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
- 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
- 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
- “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
- “backups will fail unless they are frequently restored from +
end-to-end verified”, etc.