What is REST API Security?

Back to learning

REST API security protects HTTP resources that are exposed through predictable routes and methods. REST is simple to consume, which is why it became common. That same simplicity makes it easy for attackers, scrapers, and overactive clients to enumerate resources, replay tokens, abuse public endpoints, or push expensive operations until origin systems slow down.

The REST-specific risk is not only injection. It is whether the caller is allowed to do this action on this resource, with this method, in this session, from this context.

Resource-Level Authorisation

REST routes often expose objects directly: /users/123, /orders/98421, /accounts/{id}/addresses, or /api/products/{sku}. Authentication proves who the caller is. Authorisation decides whether that caller can access the specific resource. Many serious REST failures happen when the API checks the token but not the object relationship.

A common example is an order history endpoint. A logged-in user requests GET /api/orders/1001 and receives their own order. They then change the ID to 1002 and receive someone else's order. The request is authenticated, the method is valid, and the route exists. The failure is missing resource-level authorisation.

Every sensitive REST route needs that check close to the resource. It should not rely on the client hiding IDs or the frontend avoiding certain links.

Method Semantics and Token Handling

REST security should respect HTTP method intent. GET should be safe and read-only. POST should create or trigger a controlled action. PUT and PATCH should check both the resource and the fields being changed. DELETE should require strong authorisation and evidence because recovery may be hard.

Tokens need the same discipline. Bearer tokens, JWTs, OAuth access tokens, API keys, and session cookies should be short-lived where practical, scoped to the least access required, validated on every protected route, and logged without leaking secrets. A token that works for product search should not automatically work for account export, password reset, or admin actions.

For browser-facing REST APIs, CSRF and cookie settings still matter. For mobile and server-to-server APIs, replay, stolen keys, stale credentials, and missing rotation often become the bigger problem.

Validate Shape, Origins, and Errors

Schema validation gives REST APIs a clear contract. The route should reject missing fields, unexpected types, excessive payloads, wrong content types, and parameters outside the allowed shape before application code does expensive work. This helps with injection defence, but it also catches broken clients and probing.

CORS should be narrow rather than copied from a development setup. An API that allows any origin, any method, and credentials together is giving browsers permission to send sensitive requests from places the team did not intend. CORS is not an authentication system, but it is part of controlling where browser-based calls are allowed to come from.

Error responses should help legitimate clients without teaching attackers. A 401 or 403 can be clear enough for a developer while avoiding details about whether a user ID exists, which token claim failed, or which internal service threw the exception. Server errors should be logged with detail internally and returned safely externally.

Public Endpoints Need Abuse Controls

Public REST routes are often treated as low risk because they do not require login. In practice, they can expose valuable data or expensive origin work. Product search, pricing, availability, booking, quote, and content APIs are common scraping targets. Login, registration, password reset, and token routes attract credential attacks.

Rate limits should be route-aware and keyed on more than IP address. API key, auth header, route, country, ASN, TLS fingerprint, HTTP/2 fingerprint, request headers, response codes, and bot signals can all help separate ordinary use from automation. The right action may be log, throttle, challenge, block, or protect origin capacity during a surge.

Logging That Supports Decisions

REST API logs should answer operational questions. Which route was called? Which resource was requested? What auth context and scope were present? Was the schema valid? Which rate key or fingerprint was used? What response code came back? Was the request allowed, challenged, throttled, or blocked?

Peakhour's approach is to keep REST controls in the same request path as WAF, API schema, bot, rate limiting, and DDoS decisions. That lets teams protect ordinary HTTP APIs without pretending every problem is a code vulnerability. Sometimes the risk is a bad payload. Sometimes it is a valid request used too often, on the wrong resource, by the wrong client.

Those records are also what make tuning possible. If a rule blocks partner traffic, the team needs to see the route, key, action, and customer impact before changing enforcement. The rate-limit decision matrix is a useful next step for turning REST API evidence into reviewable limits rather than broad IP blocks.