Secure API Design
A track of P57 · Application & API Security.
Where authN and authZ live, what belongs at the request boundary, error hygiene without enumeration oracles — and the flagship harden-a-vulnerable-API capstone.
Your login endpoint answers "no account with that email" when the address is unknown, and "incorrect password" when it exists. It is friendlier that way, and it also means anyone can feed a list of a million email addresses to your API and receive back the subset that holds accounts with you — which, if you are a medical service or a dating app, is a disclosure that matters regardless of whether a single password is ever cracked. Nothing here is a bug in the sense of a crash. It is a design decision that leaked, and this track is about making those decisions well.
It opens with placement, because most access-control failures are a question of where rather than whether. Authentication establishes identity once, at the boundary; authorization must be decided per request and per object, close enough to the data that no path reaches it unchecked. A check scattered across handlers is a check that a new handler will forget. You will look at what belongs at the boundary — parsing, size limits, schema validation, identity resolution — and what has to live deeper, and why that division is what makes the guarantee hold as the API grows.
Then error hygiene, generalising the login example: any difference in response — message, status code, or timing — that varies with the existence of a resource is an oracle an attacker can query. The discipline is to be uniform where existence is sensitive, and specific where it genuinely helps a legitimate caller. The track ends with the pillar's flagship: a working, vulnerable API, handed to you to harden. It contains several of the classes from the previous track, and closing them all without breaking the endpoints that are supposed to work is the whole exercise — which is the actual job, rather than a demonstration of it.