---
{
  "title": "REST API security",
  "summary": "REST API security combines transport protection, authentication, operation-level authorization, input handling, and resource limits.",
  "topic": "offensive",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    7
  ],
  "aliases": [],
  "sources": [
    {
      "title": "OWASP: REST Security",
      "url": "https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

REST API security combines transport protection, authentication, operation-level authorization, input handling, and resource limits. Each endpoint is a security boundary even if the product interface never calls it directly. API keys identify clients but do not automatically establish a user's permissions.

## A practical example

A mobile application's backend checks each record request independently. It accepts only documented methods and content types, scopes results to the caller, and avoids returning unnecessary internal fields simply because they exist in the data model.

## What to check

Inventory endpoints and versions, enforce authorization near data access, validate requests and response fields, and apply limits to costly operations. Include administrative, deprecated, and partner endpoints.

## A common pitfall

Protecting only the visible interface leaves direct API calls exposed. TLS secures the connection but does not prevent a valid client from making an unauthorized request.

## Think it through

Should an undocumented endpoint be treated as inaccessible?

**Answer:** No. If it is deployed and reachable, callers can discover it and it needs the same security review as documented endpoints.

## Follow an operation across boundaries

Consider a fictional appointment API. Creating an appointment involves a caller, a patient record, an available slot, and a confirmation message. These are separate decisions: a valid token does not establish ownership of the patient record, and a permitted appointment does not justify returning the patient's entire history. The response deserves its own review rather than being whatever the database happens to return.

Write an operation table before selecting tools. For each route, record who can call it, which objects they may use, required fields, expected response fields, and the cost of processing the request. A small JSON request can trigger an expensive report or thousands of outgoing messages. Rate limits should reflect those effects, with special care for bulk endpoints and background tasks.

Version changes create another boundary. Suppose the new appointment route fixes authorization but an older mobile client still reaches the previous version. Security depends on both deployments until the old route is removed or brought under the same policy. An endpoint inventory therefore needs owners and retirement dates, not only URLs.

## Build a small review matrix

Using an isolated training service, prepare accounts for a receptionist and two patients. Check permitted operations first, then verify that each patient cannot read or change the other's appointment. Compare list responses with individual-record responses, because filters and serialization often differ. Record expected denials as carefully as successes. Finally, consider what the application logs without copying tokens or patient details into the test report. This exercise separates transport, identity, authorization, data exposure, and operational limits into questions you can actually answer.

## Related concepts

- [[authorization]]
- [[http]]
- [[input-validation]]