CHAPTER 9
APIs, Rate Limiting and Security
Designing interfaces, protecting capacity, and authenticating and authorising callers.
Source: Chapter 9 PDF, pp. 1–9
Learning objective
Design predictable APIs, choose a pagination and rate-limiting strategy, distinguish authentication from authorisation, and apply practical security controls.
PDF page 11. What is an API? p. 1
Imagine a shopping app that needs to display your orders. It does not access the database directly. It sends a request to an API, which defines how software can ask for information or perform an operation.
| Request | Purpose |
|---|---|
| GET /v1/orders/123 | Retrieve order 123. |
| POST /v1/orders | Create a new order. |
| DELETE /v1/orders/123/items/9 | Remove an item from the order, if allowed. |
A common design principle is to model resources with nouns and use HTTP methods for operations. Use consistent naming, define schemas with OpenAPI or Protobuf, and return predictable error bodies with a code, message, details and request ID.
PDF page 22. Pagination: return large lists in manageable pieces p. 2
An order history may contain tens of thousands of records. Pagination returns a smaller set at a time, reducing payload size and work.
| Style | Request example | Strength | Caveat |
|---|---|---|---|
| Offset / limit | ?offset=100&limit;=20 | Simple; can jump to a page. | Large offsets can be slow; inserts can shift pages. |
| Cursor / keyset | ?after=cursor&limit;=20 | Often stable and efficient for growing lists. | Needs a suitable ordered key; arbitrary page jumps are harder. |
| Time / token | ?since=timestamp or next_page_token | Useful for feeds and synchronization. | Requires careful ordering and tie-breaking. |
Rule of thumb: Prefer cursor pagination for large or growing collections such as feeds, messages and logs.
3. What is an API gateway? p. 2
An API gateway is a common entry point that handles shared API concerns before requests reach the services that own the business logic.
PDF page 34. Rate limiting: protect the service from overload p. 3
Rate limiting controls how many requests a caller can make over a defined interval. It protects capacity, encourages fair use, controls cost and helps mitigate abuse. Limits may be keyed by IP, user, API key, tenant or endpoint.
A token bucket holds up to b tokens and refills at r tokens per second. Each request consumes a token. If no token is available, the request can be rejected or delayed. For example, a bucket holding 20 tokens and refilling at 5 per second permits a burst of up to 20 requests, then replenishes over time.
Common algorithms
| Algorithm | Idea | Trade-off |
|---|---|---|
| Token bucket | A request consumes a token; tokens refill over time. | Allows bursts; tune capacity and refill rate. |
| Leaky bucket | Queue drains at a controlled rate. | Smooth output; may delay or drop bursts. |
| Fixed window | Count requests per fixed interval. | Simple, but has boundary bursts. |
| Sliding-window log | Store request timestamps within the rolling interval. | Accurate, but uses memory per request. |
| Sliding-window counter | Estimate a rolling count from adjacent windows. | Low memory; approximate. |
PDF page 45. Rate limiting across multiple servers p. 4
If four gateway instances each enforce a separate limit of 100 requests per minute, one user may exceed the intended global allowance by using all four. A distributed limiter coordinates counters across instances.
A shared store such as Redis can hold counters. Updates must be atomic, for example through a suitable script, so concurrent gateways do not all read the same old count and over-admit traffic. Local counters can reduce store traffic, but may allow small deviations from the global limit.
| Failure policy | Behavior | When it may fit |
|---|---|---|
| Fail open | Allow requests if the limiter cannot be checked. | Some low-risk endpoints where availability matters. |
| Fail closed | Reject requests if the limiter cannot be checked. | Sensitive endpoints such as login or OTP verification. |
| Local fallback | Apply emergency limits at each instance. | A balance between availability and protection. |
6. Authentication vs. authorisation p. 4
| Concept | Question | Examples | ||
|---|---|---|---|---|
| Authentication (AuthN) | Who are you? | Passwords + MFA, passkeys, OIDC/SSO, API keys, service certificates. | ||
| Authorisation (AuthZ) | What may you do? | RBAC, ABAC, ACLs, relationship-based rules and OAuth scopes. | ||
| Security rule: A user can be authenticated and still lack permission to access a particular order. Check access on the server for every protected operation. |
PDF page 57. Sessions vs. tokens p. 5
After sign-in, the application needs a way to recognize the user on later requests. One option stores session state on the server; another carries signed claims in an access token.
| Feature | Server-side session | JWT access token |
|---|---|---|
| State | Session data stored on the server. | Claims carried in a signed token. |
| Verification | Look up session ID. | Verify signature and required claims. |
| Revocation | Often straightforward to invalidate. | Immediate revocation needs additional controls. |
| Scaling | Session store must be reachable by instances. | Verification can be stateless, but expiry and revocation still need planning. |
JWT safety checklist
- Verify the signature and relevant expiry, issuer and audience claims.
- Never trust an unsigned token or accept alg: none.
- A signed JWT is not encrypted by default; do not put secrets in its payload.
- Protect credentials against theft; for browser apps, secure HttpOnly cookies are often preferable to exposing long-lived tokens to JavaScript.
PDF page 68. OAuth 2.0, OpenID Connect and PKCE p. 6
OAuth 2.0 lets an application obtain delegated access without collecting the user's identity-provider password. OpenID Connect adds an identity layer, including an ID token. Public clients such as mobile and browser apps commonly use Authorization Code with PKCE.
The application creates a verifier and sends a derived challenge in the authorization request. After the user signs in, the identity provider returns an authorization code. The app exchanges the code with the verifier, helping protect against an intercepted code being used by an attacker.
9. Webhooks: notify another service p. 6
A webhook is an HTTP request sent when an event occurs, such as a successful payment. It avoids requiring the receiving application to repeatedly poll for the result.
- Sign payloads, commonly with HMAC, and verify signatures securely.
- Include a unique event ID so duplicate deliveries can be detected.
- Retry temporary failures with exponential backoff and jitter.
- Make processing idempotent; a webhook may be delivered more than once.
PDF page 710. Security essentials p. 7
Security should be built into every layer, not added only at the API gateway. Protect data, credentials, access, infrastructure and the software supply chain.
| Area | Practice |
|---|---|
| Data in transit | Use TLS and automate certificate rotation; consider mTLS for service-to-service traffic. |
| Data at rest | Encrypt disks and databases; manage keys through KMS/HSM with rotation. |
| Passwords | Never store plaintext passwords; use Argon2id, bcrypt or scrypt with salts, plus MFA where appropriate. |
| Input handling | Use parameterised SQL, output encoding, CSP, CSRF protections and SSRF defenses. Validate schemas and sizes. |
| Access control | Least privilege, deny by default, server-side authorisation and tenant isolation. |
| Secrets | Use secret managers and short-lived credentials; never hard-code secrets. |
| Abuse / DDoS | CDN/WAF, rate limits, bot controls, request-size limits and load protection. |
| Audit and privacy | Protect audit logs; minimise personal data and define retention and deletion. |
| Supply chain | Scan dependencies, use signed artifacts and maintain software bills of materials where appropriate. |
| Zero trust | Authenticate and authorise each request regardless of network location. |
PDF page 811. Common API security failures p. 8
| Failure | Example | Protection |
|---|---|---|
| Broken access control | A user changes order ID in a URL and sees someone else's order. | Check resource ownership and permissions server-side for every request. |
| Injection | Untrusted input is interpreted as SQL or another instruction. | Parameterised queries, safe APIs and input validation. |
| Credential theft | A token leaks from unsafe storage or logs. | TLS, secure token handling, expiry and no secret logging. |
| API abuse | Automated traffic overwhelms an expensive endpoint. | Layered rate limits, monitoring and additional verification where appropriate. |
Chapter recap p. 8
| Concept | Remember |
|---|---|
| API contract | Clear requests, responses, errors, versions and pagination. |
| Gateway | Centralizes shared API controls and routing. |
| Rate limiting | Protects capacity and fairness; algorithm choice depends on burst behavior and precision. |
| AuthN / AuthZ | Verify identity, then check what it is allowed to do. |
| Sessions / tokens | Have different verification and revocation trade-offs. |
| OAuth / OIDC / PKCE | Delegate access; add identity; protect code exchange for public clients. |
| Webhooks | Verify signatures, retry safely and deduplicate events. |
| Security | Protect every layer with encryption, validation, least privilege and monitoring. |
PDF page 9Check your understanding p. 9
1. Why is cursor pagination often preferred for a large, growing collection?
- A. It makes all page jumps instant
- B. It avoids large offset scans and can reduce shifting-page problems
- C. It eliminates the need for database indexes 2. What status code is commonly used when a rate limit is exceeded?
- A. 200
- B. 401
- C. 429 3. What is the difference between authentication and authorisation?
- A. AuthN verifies identity; AuthZ checks permissions
- B. They mean exactly the same thing
- C. Authorisation happens only in the browser 4. Is a signed JWT payload automatically encrypted?
- A. Yes, always
- B. No, signing does not encrypt the payload by default
- C. Only when it has an expiry claim 5. Why should webhook receivers be idempotent?
- A. To avoid repeating the business effect on duplicate delivery
- B. To prevent the sender from retrying
- C. To bypass signature verification 6. What prevents a user from accessing another user's order by changing its ID?
- A. Hiding the order ID in the interface
- B. A longer URL
- C. Server-side resource permission checks
Answer key and explanations
| Q | Answer | Explanation |
|---|---|---|
| 1 | B | Cursor pagination can avoid deep offset scans and reduce page shifts when data changes. |
| 2 | C | HTTP 429 means Too Many Requests. |
| 3 | A | Authentication verifies identity; authorisation checks whether the action is permitted. |
| 4 | B | A signed JWT is generally readable; signing protects integrity, not confidentiality. |
| 5 | A | Webhooks may be retried, so duplicate events must not duplicate the business effect. |
| 6 | C | Every protected operation must enforce access checks on the server. |
Review questions for this chapter have not been written and reviewed yet. The chapter text above is the full source content.
Try it
References
Chapter 9 PDF, pp. 1–9; figures 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.
Tip: use ← and → keys to move between chapters.