REST API security: a checklist for every endpoint

An API is only as safe as its weakest endpoint. A team can protect the main routes well and still leave one admin route, one old version or one checkout step open. REST API security works best as a checklist you run against every endpoint, one at a time. This guide builds that checklist from the OWASP REST Security Cheat Sheet and walks through it on a checkout API.

Why REST API security is checked per endpoint

The OWASP REST Security Cheat Sheet starts from how REST works. Each call is stateless, so each endpoint has to decide on its own whether the caller may do what they ask. OWASP says non-public REST services must perform access control at each API endpoint, and that the decision should be made locally by the endpoint, with sign-in handled centrally by an identity provider that issues tokens.

So the question is never "is the API secure?" It is "does this endpoint check who is calling, what they sent, and what it sends back?"

The checklist, in four groups. Simplified from the OWASP REST Security Cheat Sheet.

Who may call it: HTTPS, tokens and keys

• HTTPS only. OWASP says secure REST services must only offer HTTPS endpoints, which protects passwords, API keys and tokens in transit. For highly privileged services it suggests client certificates as well.
• JWTs checked properly. Reject unsigned tokens ("alg":"none"). Choose the verification algorithm from your own configuration, never from the token's header. Require and check iss (a trusted issuer), aud (meant for this service) and exp (not expired). OWASP prefers signatures over shared-key MACs: with a MAC, every service that can check a token can also mint one, so one compromised service compromises every service sharing the key. See JWT security testing for the tests.
• API keys in their place. Require a key on every request to a protected endpoint, answer 429 Too Many Requests when calls come too fast, and revoke keys that break the usage terms. OWASP adds: do not rely on API keys alone for sensitive or high-value resources.

What it accepts: methods, input and content types

• Allowed methods only. Keep a list of permitted HTTP methods for each route, reject the rest with 405 Method Not Allowed, and check the caller may use that method on that record.
• Validated input. Check length, range, format and type, and use strong types such as numbers, booleans and dates in parameters. Set a request size limit and reject bigger requests with 413. OWASP suggests logging validation failures: hundreds per second means someone is probing. See input validation.
• Declared content types. For requests with a body, require a supported Content-Type and reject others with 415 Unsupported Media Type. If you accept XML, use a parser hardened against XXE.

What it sends back: types, errors and headers

• The right response type. OWASP warns: do not copy the request's Accept header into the response Content-Type. Pick a supported type that matches, or answer 406 Not Acceptable, and send JSON as application/json.
• Generic errors. No call stacks or internal hints in responses; see error handling.
• Headers for browser clients. OWASP lists Cache-Control: no-store, Content-Security-Policy: frame-ancestors 'none', a correct Content-Type, Strict-Transport-Security and X-Content-Type-Options: nosniff for API responses a browser may read.

Worked example: check a checkout API step by step

Say your shop's API has four endpoints: create a cart, add items, pay, and finalize the order. Use a staging copy and test accounts.

1. Skip a step. Create a cart, add an item, then call finalize without paying. OWASP calls this out-of-order API execution: each endpoint may check the user, yet none checks that the workflow is in the right state. The fix is to check the cart's state on the server for every request and reject invalid transitions.
2. Swap the owner. As user A, call add items on user B's cart ID. The endpoint must check that this caller owns this cart.
3. Change the method. Send DELETE or PUT to the pay endpoint. Expect 405.
4. Break the body. Send a negative quantity, a huge body and a body with Content-Type: text/xml. Expect 400, 413 and 415, with short messages.
5. Read the response headers on each endpoint and compare them with OWASP's list.

Write down every response that does not match. That list is your fix plan, and the same requests become your retest.

Management endpoints and audit logs

Admin and health routes are easy to forget. OWASP's advice: avoid exposing management endpoints to the internet. If they must be reachable, require strong sign-in such as multi-factor authentication, serve them on a different port or host, preferably on a separate network interface and a restricted subnet, and restrict access with firewall rules or access lists. A health check that answers the whole internet is still a management endpoint.

For logs, OWASP suggests writing audit entries before and after security-related events, logging token validation errors to spot attacks, and cleaning log data first to stop log injection.

Frequently asked questions

Is an API key enough to protect an API?

Not for sensitive data. OWASP says API keys help against abuse and heavy traffic, but are easy to compromise when issued to third parties, so do not rely on them alone for sensitive or high-value resources.

Why check workflow order if every endpoint checks the user?

Because a signed-in user can still call the last step first. Only a server-side check of the workflow state stops a checkout without payment.

Do browser security headers matter for a JSON API?

Some do. OWASP lists a short set for API responses that browsers may read, including Cache-Control: no-store and X-Content-Type-Options: nosniff.

What status code should a wrong content type get?

A request body with an unsupported type gets 415. A client asking for a response type you do not offer gets 406.

Should each microservice check access itself?

Yes. OWASP recommends that each REST endpoint make its own access control decision, using tokens from a central identity provider, rather than trusting that another service already checked.

Get started

List every endpoint your API exposes, including admin and old versions. Run the checklist on the three that handle money or personal data first, then the rest.

If you want a second pair of eyes, whitehatstoic's security testing covers web app and API review, with a written report, fixes and a retest after fixes. It is scoped after a short call, and no test can promise to find every weakness.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.