Securing a web API

Think in layers

No single control secures an API. Defence comes from several layers, each assuming the others may fail.

100%

Figure SDA-RWS-14-1 · API security layers · © forcsguy.com

1. Transport

Use HTTPS everywhere, with modern TLS and HSTS. Never accept credentials over plain HTTP.

2. Authentication: who is calling?

• Users: OAuth 2.0 / OpenID Connect access tokens, or secure session cookies for browsers (see the earlier lessons).
• Machines: API keys or client credentials, stored as hashes, scoped, and rotatable.
• Send credentials in the Authorization header, never in URLs.
• Keep token lifetimes short, support revocation, and protect refresh tokens carefully.
• Add multi-factor authentication for sensitive accounts, and protect login endpoints with rate limits.

3. Authorisation: what may they do?

This is where most real API breaches happen.

• Check on every request, on the server, both the action (role or scope) and the specific object. "Is this user logged in?" is not enough; ask "may this user read order 123?" (broken object-level authorisation is the top API risk).
• Apply least privilege: tokens carry only the scopes they need.
• Never rely on the client hiding buttons.
• Do not expose sequential ids as a security measure. Use authorisation checks (random ids only help a little).

4. Input and output

• Validate every input against a schema: types, lengths, ranges, allowed values. Reject unknown fields (prevents mass assignment, where a caller sets fields like isAdmin).
• Use parameterised queries to prevent SQL injection, and encode output to prevent injection into other systems.
• Limit request size and file types, and scan uploads.
• Return only the fields needed (avoid excessive data exposure), and paginate lists.
• Return generic error messages to clients and keep detail in logs, so errors do not leak internals.

100%

Figure SDA-RWS-14-2 · Two ways a caller proves who it is · © forcsguy.com

100%

Figure SDA-RWS-14-3 · Signing each request with a shared secret (HMAC) · © forcsguy.com

Image: Spanish Coches · CC BY 2.0 · Source · Wikimedia Commons: Peaje - Toll - Péage (5020183265)

5. Abuse protection

• Rate limiting per user, key and IP, with stricter limits on expensive or sensitive endpoints.
• Quotas and timeouts; protect against huge queries (depth limits in GraphQL, page size caps).
• Bot and credential-stuffing defences: lockouts, delays, CAPTCHAs, breached-password checks.

6. Webhooks and service-to-service calls

• Sign outgoing webhooks with an HMAC over the body and a timestamp. Receivers verify the signature in constant time, reject old timestamps and handle events idempotently.
• Between services use mutual TLS or signed tokens, and network policies, instead of trusting "internal" traffic.

7. Browsers: CORS and cookies

• Configure CORS with an explicit allow-list of origins. Never reflect any origin with credentials enabled.
• Cookies: HttpOnly, Secure, SameSite. Protect state-changing requests from CSRF.

An example worth knowing: in 2021 a flaw in a popular Java logging library (Log4Shell) let attackers run their own code simply by getting a crafted string written to a log.

100%

Figure SDA-RWS-14-4 · How untrusted text became remote code execution · © forcsguy.com

8. Secrets, data and visibility

• Keep secrets in a secrets manager, not in code or images, and rotate them.
• Encrypt sensitive data at rest, and minimise what you store.
• Log authentication events and authorisation failures (never secrets), and alert on anomalies. Keep an inventory of your APIs so old versions and forgotten endpoints do not stay exposed.
• Keep dependencies patched, and test: security tests, dependency scanning, and periodic penetration testing.

More on this site