You are reviewing a new public API before launch. What do you check, in priority order?

1. Object-level authorization — check this first, on every endpoint

The most common serious API vulnerability. For each endpoint accepting an identifier, verify the handler confirms the caller is entitled to that specific record, not merely to call the endpoint.

The robust pattern is to scope the query — WHERE id = ? AND customer_id = ? — rather than fetch and compare, because forgetting it returns nothing instead of returning someone else's data.

Test it mechanically: authenticated requests from user A for user B's resources, across every endpoint in the specification.

2. Function-level authorization

Can an ordinary user call an administrative endpoint? Check that authorisation is enforced on the endpoint itself rather than relying on the UI not offering it. Enumerate the routes and check each, because undocumented admin routes are routinely left unprotected.

3. Mass assignment and excessive data exposure

Inbound: does the request body bind onto an internal model? Then a caller can set role, accountBalance or emailVerified. Require explicit DTOs.

Outbound: does the response return the whole object with the client expected to display only some of it? Check what is actually serialised, including nested relations.

4. Rate limiting and resource consumption

Per identity, not only per IP. Check for unbounded operations: missing pagination limits, expensive filters, deeply nested queries if the API is GraphQL, and unbounded upload sizes.

5. Input validation and injection

Schema validation rejecting unknown properties. Parameterised queries. And SSRF specifically — any parameter accepting a URL is a finding until proven otherwise.

6. Authentication and token handling

Algorithm pinned, issuer and audience validated, expiry checked, token lifetime appropriate, refresh rotation with reuse detection.

7. Error handling and logging

Errors that do not leak stack traces, internal identifiers or whether an account exists. Logs that do not contain tokens, card numbers or personal data.

8. The contract itself

A published OpenAPI specification, with schema diffing in CI so a breaking change fails the build — which is a security control as well as a compatibility one, because undocumented endpoints are unreviewed endpoints.

What a strong answer adds

Proposing that items 1 and 2 become automated tests generated from the API specification rather than a review checklist. A review catches what exists today; a generated test catches the endpoint added next month, and authorisation gaps are introduced continuously rather than once.