% API Security
% Michael Stone
% November 30, 2021

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

<hr/>

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.