REST APIs inherit the same threat landscape as any web service, and security must be designed in from the start. The foundation is HTTPS, which protects credentials and payloads in transit and lets clients trust the server's certificate. Beyond transport security, the OWASP API Security Top 10 highlights injection, broken authentication, and excessive data exposure as recurring issues, so input validation, output filtering, and least-privilege authorization belong in every endpoint. Authorization is best modeled around scopes attached to the authenticated identity, so each token grants only the actions it actually needs.
Several authentication mechanisms are commonly paired with REST. API keys are the simplest: a shared secret sent in a header such as X-API-Key. They are easy to issue and use, but they identify a caller only loosely and offer no built-in scoping, so they are best for service-to-service traffic with low sensitivity or for first-party clients where the key can be rotated frequently. OAuth 2.0 is the dominant framework for delegated access and third-party integrations; the resource owner grants an application a scoped access token issued by an authorization server, and the token is refreshed on a separate flow when it expires. JWTs are the most common token format used inside OAuth 2.0: compact, self-contained, signed (and optionally encrypted) structures that carry claims such as user ID, scopes, and expiration so that servers can verify identity without a session store, which fits naturally with REST's statelessness requirement.
Beyond authentication, a few cross-cutting concerns complete the picture. CORS headers tell browsers which origins, methods, and headers are allowed to call the API, which is essential when browser-based clients on different domains consume the service. Rate limiting protects availability by capping request volume per client—often exposed through headers like X-RateLimit-Remaining and X-RateLimit-Limit—and pairs naturally with the 429 response discussed earlier. Idempotency keys, sent on POST or PUT operations, ensure that retries from unreliable networks do not double-charge a payment or create duplicate records: the server remembers the key for a window of time and returns the original response on subsequent calls with the same key, making the operation effectively idempotent even when the underlying method is not.