API Security — An Overview

Summary#

API security is the set of properties a contract must guarantee about its callers, its payloads, and its side-effects. Five properties — the CIA triad plus the two halves of access control — frame everything else:

• Confidentiality — only the intended caller can read the bytes on the wire and in storage.
• Integrity — the bytes the server received are the bytes the caller sent, unchanged.
• Availability — the API is reachable by legitimate callers, even under attack.
• Authentication — the API knows who the caller is.
• Authorization — the API knows what this caller is allowed to do.

Most production APIs ship something for each property. The interview signal — and the day-two-of-a-breach signal — is whether the designer can name which property failed when something went wrong. “We had a breach” is a sentence; “an unauthenticated caller exfiltrated objects because object-level authorization wasn’t enforced on the read path” is a postmortem.

This page is the map. The companion pages in the Security topic each take one box on the map and go deep — TLS is the confidentiality-and-integrity layer on the wire, OAuth 2 is one common AuthZ protocol, OpenID Connect is one common AuthN protocol, input validation keeps payload-shaped attacks out of the back-end, CORS keeps cross-origin browser requests from forging credentials.

Why it matters#

Three concrete reasons API security is a first-class design concern, not a thing to bolt on later:

• The blast radius is the API’s, not the implementation’s. A SQL-injection bug in the order service leaks every customer’s data via the order API — it doesn’t leak via the order service’s internal log files. The API is the surface attackers reach for. The data-loss event is shaped by the contract.
• Security failures are contract failures, not code failures. Broken object-level authorization (BOLA) is the most-reported API vulnerability of the last decade. It’s not a bug in any one endpoint — it’s a contract that lets GET /invoices/123 return invoice 123 to any authenticated caller, regardless of whether they own it. The fix is contract-level (every read enforces ownership) before it is code-level (one endpoint at a time).
• Compliance is downstream of design. SOC 2, PCI DSS, HIPAA, GDPR — all read like checklists, but they reduce to “show your API enforces these properties everywhere.” A contract that was designed for the properties from day one passes audit; a contract that has them retrofitted endpoint-by-endpoint never finishes.

The senior-signal phrasing in an interview: “Security is part of the contract, not a layer on top of it. Every endpoint has a story for confidentiality, integrity, availability, AuthN, and AuthZ — even the ones that look obviously read-only.”

How it works#

The five properties on one slide#

A good API-design review for a single endpoint walks all five rows. Most production bugs are one of these rows being unspecified — not actively wrong, just absent.

The OWASP API Security Top 10 (2023)#

The Open Worldwide Application Security Project maintains a top-10 list specifically for APIs. The 2023 edition is the working vocabulary for API security in 2026. In rough order of how often each shows up in production:

1. API1: Broken Object Level Authorization (BOLA) — GET /invoices/{id} returns any caller’s invoice. The single most common API vulnerability.
2. API2: Broken Authentication — weak tokens, missing MFA, JWT signature not verified, refresh tokens not rotated, password reset flows that leak.
3. API3: Broken Object Property Level Authorization — a field on a resource that should be admin-only (role, verified, balance) is writable via a generic PATCH /users/{id}.
4. API4: Unrestricted Resource Consumption — no rate limit, no payload-size cap, no query-complexity limit on GraphQL. One caller can spend all of your CPU or all of your downstream budget.
5. API5: Broken Function Level Authorization — admin endpoints accessible by non-admin callers because the AuthZ check is on the URL prefix, not on the function.
6. API6: Unrestricted Access to Sensitive Business Flows — bulk purchase, gift-card redemption, contest entry — flows where the rate is the abuse vector, not any single call.
7. API7: Server-Side Request Forgery (SSRF) — your API accepts a URL and fetches it server-side, which an attacker uses to reach internal services (169.254.169.254 AWS metadata, etc.).
8. API8: Security Misconfiguration — TLS with weak ciphers, CORS with *, verbose error messages leaking stack traces, default credentials left on.
9. API9: Improper Inventory Management — you forgot you had a v1 endpoint. It’s still live. It’s still unpatched. An attacker found it before you did.
10. API10: Unsafe Consumption of APIs — your API trusts a third-party API’s response without validating it. The third party gets compromised; you get compromised.

Notice the shape: four of the ten are authorization failures (BOLA, object-property AuthZ, function-level AuthZ, business-flow AuthZ). Authorization is the single biggest API-security risk in 2026, and the one most often shipped half-done.

The threat-model questions#

For every endpoint, the designer should be able to answer:

• Who can call this? Anonymous? Authenticated user? Specific role? Specific scope?
• What identity is required? Session cookie? Bearer token? mTLS client certificate? API key?
• What ownership check runs after AuthN? “Is this user the owner of resource X?” (BOLA defence). “Is this user in the same org as resource X?” “Is this user an admin on this resource?”
• What rate limit applies? Per IP? Per API key? Per user? Per resource? Per business flow?
• What can the caller include in the payload that they shouldn’t be able to set? (Object-property AuthZ — the role field on PATCH /users/{id}.)
• What does this endpoint reveal in error responses? “Invoice 999 not found” vs “you are not authorised to view invoice 999” — the latter leaks existence.
• What auditable record does this endpoint produce? Every write should be auditable; every sensitive read often should be too.

Where each property is enforced#

   Caller
     │
     │   TLS (confidentiality + integrity on the wire)
     ▼
   Load balancer / WAF
     │
     │   Rate limiting (availability)
     │   IP allowlist / DDoS protection (availability)
     ▼
   API gateway
     │
     │   AuthN (who are you? — token validation)
     │   Coarse AuthZ (does your token have any access to this surface?)
     ▼
   Application
     │
     │   Fine-grained AuthZ (ownership / RBAC / ABAC)
     │   Input validation (integrity, SSRF defence)
     │   Business-flow rate limiting (availability)
     ▼
   Storage
     │
     │   Encryption at rest (confidentiality)
     │   Audit log (forensics)

The layered structure matters because each layer has different capabilities. A WAF can rate-limit by IP but cannot check ownership; the application can check ownership but cannot afford to be the first line of defence against a 10Gbps DDoS. Design for defence in depth — five properties, multiple layers, no single component owns all of any property.

Variants and trade-offs#

API security looks different in different deployment models:

The properties are universal; the mechanisms shift. An internal API does not need OAuth 2’s user-consent flow — but it still needs AuthN (who is the calling service?) and AuthZ (is that service allowed to make this call?). A mobile API still needs OAuth 2 but also has to assume the device is hostile.

When this is asked in interviews#

In an API-design interview, security can be the focused round or a 5-minute follow-up to the main design. The senior signal in either case is the same: walk the five properties for the endpoint under discussion, name what enforces each, name what could break each. The lazy answer is “we use HTTPS and OAuth” — that addresses one and a half of the five.

Specifically:

• AuthN vs AuthZ vocabulary. Use both words; use them correctly. “OAuth 2 is authorization, not authentication; we’d layer OIDC on top for identity.” (See authentication-vs-authorization and oauth-2-authorization.)
• Object-level authorization. Name BOLA explicitly. Every read endpoint that takes an ID needs an ownership check. The candidate who says “and we’d verify the caller owns the resource” before the interviewer asks has cleared the bar.
• Rate limits as a security control, not just a fairness one. Availability is one of the five properties. Rate limiting is the first defence.
• Input validation, including SSRF. Any endpoint that accepts a URL or a file path is a SSRF risk until proven otherwise. Reject localhost, RFC 1918 ranges, and the AWS metadata endpoint at the gateway.
• Error responses that don’t leak. “Not found” is sometimes “not authorised” — pick one and use it everywhere.
• An evolution story. “We’d add API4 mitigations (rate / payload caps) in v1; we’d add scoped tokens in v2; we’d add webhook signing when we add webhooks.” Security can ship in phases as long as it ships.

For the strongest summary: “Every endpoint has a story for confidentiality, integrity, availability, AuthN, and AuthZ — and the most common failure mode is missing AuthZ, specifically object-level ownership checks on reads.” That single sentence covers BOLA, the senior vocabulary, and the right framing.

Related concepts#

• Authentication vs Authorization — the two-word vocabulary every API designer must use precisely.
• Transport Layer Security (TLS) — the wire-level enforcement of confidentiality and integrity.
• OAuth 2 — The Authorization Framework — the dominant AuthZ protocol; the four roles, the grant types, the pitfalls.
• Securing APIs Using Input Validation — payload-shaped attacks, SSRF, and the validation surface.
• API Security — A High-Level Recap — the consolidated checklist; this page is the why, that page is the what.