How would you secure a public-facing REST API?

Securing an API is about controlling who can call it, what they can do, and what they can send — on every single request, because an API is stateless and each request must stand on its own.

Authentication vs authorization

These are distinct and both required. Authentication proves who the caller is — typically a short-lived bearer token from OAuth2/OIDC, validated on every request (signature, expiry, audience). Authorization decides what that authenticated caller may do. The single most common and damaging API flaw is broken object-level authorization (BOLA/IDOR): the code authenticates the user but then returns object /orders/123 without checking that order 123 actually belongs to them. Always verify ownership of the specific resource, not just that someone is logged in.

Transport and input

• TLS everywhere — never accept plaintext, and don't put secrets or tokens in query strings where they land in logs.
• Validate and constrain input server-side against a strict schema; reject unexpected fields and oversized payloads. Never trust client-side validation.
• Parameterize queries and encode output to block injection.

Abuse and visibility

• Rate limiting and quotas protect against brute force, scraping, and denial of service; tune them differently for authenticated vs anonymous callers.
• Logging and monitoring of auth failures and anomalous access patterns lets you detect attacks in progress.
• Minimize data exposure — return only the fields the client needs, so the API doesn't leak internal data through over-broad responses.

What interviewers look for

Candidates who only say "use API keys" miss the point. The strong answer separates authentication from authorization, calls out object-level access checks (BOLA/IDOR) as the top real-world risk, and rounds it out with TLS, input validation, and rate limiting.