1. API security and auth

A request hits your API carrying a credential that is valid, unexpired, and genuinely belongs to a real user of your product. It is asking for a record that belongs to a different customer. Nothing about the credential is wrong, and serving that request is still the thing you go out of business for.

API security and auth is the design of the trust boundary that catches it: the checks an API runs on every request to establish which principal is calling, decide whether that principal may do this thing, and carry or withdraw those two answers safely across clients, third parties, and internal services.

In interviews this almost never arrives as its own section. It comes as a follow-up, usually a few minutes long, when the interviewer adds a mobile client, a third-party integration, or an org chart with admins and guests to a design you have already sketched. Product-style backend rounds push hardest on credentials and permission models. Infrastructure and platform rounds push on where enforcement runs and what happens when it breaks.

For any unfamiliar API, split the trust boundary into those two decisions and state what happens to a credential once access is withdrawn.