API Security Guide: What to Secure, in What Order

API security is the practice of making sure every request to your API is authenticated as someone, authorized for that specific thing, and safe to process. Most breaches that get labelled "API security incidents" are not exotic. They are a missing authorization check, a token that lived too long, or a flag someone flipped in a config file. This guide is the map of everything published here on the subject, ordered the way you should actually work through it.

The four layers, in priority order

Almost every real API vulnerability lands in one of four layers. They are listed here in the order that returns the most risk reduction per hour of work, which is not the order most teams tackle them in.

1. Authorization. Can this authenticated caller do this specific operation on this specific object? Broken object-level authorization is the most common serious API flaw and the least likely to be caught by a scanner.
2. Authentication and tokens. Who is calling, how is that proven, and how long does the proof stay valid?
3. Surface and design. What is exposed, what does it return, and what do the errors leak?
4. Machine and agent identity. What happens when the caller is not a person, which is now most of your traffic.

If you only have one afternoon, spend it on layer one. Authentication failures are loud and get caught. Authorization failures are silent and get exfiltrated.

Layer 1: Authorization

Authentication tells you who is calling. Authorization decides what they are allowed to touch. The gap between those two sentences is where most API data loss happens, because the check for "is this record yours" often lives in application code that nobody tests systematically.

• API authorization patterns, the patterns themselves and when each one fits.
• RBAC vs ABAC vs ReBAC vs PBAC, how to pick a permission model before you write the checks.
• M2M authorization for apps, APIs, and web services, the service-to-service case.
• OpenFGA, if per-object permissions have outgrown role checks in application code.

Layer 2: Authentication and tokens

Token strategy is a design decision with a long tail. Choosing JWTs because they are stateless, then discovering you cannot revoke one, is a mistake that surfaces months later during an incident. Decide the revocation story first and let that pick the token format.

• JWT vs opaque tokens, the choice and its consequences.
• Understanding JWT, from basics to advanced security.
• JWT, OAuth, OIDC, and SAML compared, what each protocol is actually for.
• REST API authentication methods.
• Known vulnerabilities in SAML, OAuth 2.0, OIDC, and JWT.

Layer 3: Design and surface

A well-designed API is easier to secure because there is less of it, and because the parts that exist behave predictably. Error handling belongs in this layer rather than in an operations backlog: error responses are the channel through which an API tells an attacker how it works internally.

• RESTful API design best practices.
• Beginner guide to RESTful API design.
• API error code management, including what not to put in an error body.
• Five common RESTful API security risks.
• Third-party API security, the APIs you consume rather than publish.

Layer 4: Machine and agent identity

Most API traffic is no longer a person behind a browser. It is services, jobs, and increasingly AI agents acting on a user's behalf. That breaks assumptions built into human-shaped auth: sessions that assume a login screen, tokens sized for a workday, and audit logs that record a service account rather than the human who triggered the work.

• Beyond passwords and API keys, identity infrastructure for autonomous systems.
• Credential lifecycle for AI agents, from 24-hour tokens to ephemeral ones.
• Machine identity as an enterprise risk.
• MCP vs API, how agent-facing interfaces differ from ordinary ones.
• The MCP server identity model.

What actually breaks, from the incident record

Reading incident write-ups is more useful than reading checklists, because real failures rarely look like the categories in a framework. Three recent cases cover most of the shapes: a configuration flag, a protocol flow abused as designed, and a public endpoint that was never meant to be enumerated at scale.

• ServiceNow's requires_authentication=false, one boolean, worldwide exposure.
• OAuth device flow vulnerabilities, a legitimate flow turned into a phishing primitive.
• The Instagram API scraping crisis, when public data at scale becomes a breach.
• Securing APIs inside identity and access management.

Tooling

Tools find the classes of problem that pattern-match well: injection, misconfiguration, exposed endpoints, weak transport. They do not find broken object-level authorization, because a scanner has no idea which records are supposed to belong to which tenant. Buy tools for the first category and use code review and tests for the second.

• API security testing tools.
• API management platforms, where rate limiting and gateway policy live.
• Secrets management tools, for the keys the API depends on.

A practical working order

If you are starting from nothing and want a sequence rather than a reading list, this is the order that tends to hold up. Each step assumes the previous one is done, because doing them out of order produces work you throw away.

1. Inventory the endpoints. You cannot secure a surface you have not listed, and shadow endpoints are common.
2. For every endpoint that returns or mutates a record, verify there is an ownership or tenancy check, and write a test that fails without it.
3. Settle the token story: format, lifetime, refresh, and how you revoke one in an incident.
4. Strip internal detail out of error responses and make error codes stable and documented.
5. Separate machine callers from human ones so the audit trail can tell them apart.
6. Add scanning and gateway policy last, once the structural work is done, so the findings are signal rather than noise.