Overview
Most modern APIs follow REST conventions, so understanding REST is the starting point for securing APIs. This lesson reviews REST concepts with a security lens.
Learning objectives
- Describe REST's resource-and-method model.
- Explain statelessness and its security implications.
- Frame the API-security concerns that follow.
Core concept
REST (Representational State Transfer) models an API as resources identified by URLs, acted on with HTTP methods (GET read, POST create, PUT/PATCH update, DELETE remove), typically exchanging JSON. REST APIs are usually stateless — each request must carry its own authentication (there is no server-side session assumed between calls). This means every request independently presents credentials (e.g. a token) and must be independently authenticated and authorized.
How it works
A client calls resource endpoints (e.g. GET /api/orders/42) with the appropriate method, including credentials on each request. Because REST is stateless and endpoints are directly callable, security cannot rely on any UI flow or prior step — each endpoint and method must enforce its own authentication, authorization, and validation. The method also carries meaning: reads vs writes vs deletes should be consistently access-controlled. This resource/method/stateless model shapes every API-security concern in this module.
Practical example
An orders API exposes GET /api/orders/{id} (read), POST /api/orders (create), and DELETE /api/orders/{id} (delete). A client includes an auth token on every call. Since any client can call these directly, each must verify the token (authentication), confirm the caller may act on that order (authorization), and validate inputs — independently, on every request and method. The stateless, directly-callable nature is exactly why per-endpoint enforcement is mandatory.
Cybersecurity relevance
REST's model explains why API security is per-endpoint and per-request: statelessness means credentials travel with each call and must be verified each time; direct callability means the UI provides no protection. The upcoming lessons — API authentication, object-level authorization, rate limiting, validation, and error handling — all follow from this. Recognizing an API as a set of independently-callable, stateless resource endpoints is the foundation for assessing and defending it.
Common mistakes
- Assuming a UI flow protects API endpoints — they are directly callable and stateless.
- Relying on a prior request's state in a stateless API instead of authenticating each call.
- Inconsistent access control across methods on the same resource.
Key takeaways
- REST models APIs as resources (URLs) acted on with HTTP methods, exchanging JSON, and is typically stateless.
- Statelessness and direct callability mean every endpoint and method must independently enforce authentication, authorization, and validation.
- This model underpins all API-security concerns; each request carries its own credentials and must be verified per call and per method.
Check your understanding
- Why does REST's statelessness require each request to be independently authenticated?
- Why can't an API rely on the UI or a prior step to protect its endpoints?