API Security

• By 2026 most traffic is API-to-API; the 'web app' is a skin over a larger, quieter attack surface.
• API flaws (BOLA, mass assignment, unauthenticated enumeration) are the top findings in every commercial pentest.
• Rate limits and schema validation are cheap, are measurable, and stop whole incident classes before the business logic runs.

It is not a person complaining to a teller anymore; it's an instruction channel that must enforce its own limits.

• Identity arrives via API keys or tokens; the backend must check scope per request, not just 'valid token'.
• Object-level authorization (BOLA): each record fetch must verify the calling principal owns the record.
• Validation: schema/type checks reject junk before any processing, and input is deserialized defensively (no mass assignment).
• Abuse controls: rate limiting, quota, weird-pattern alerts — the API contract includes 'how fast and how often'.

• An e-commerce API filters an abusive scrape by adding per-token rate limits and blocking the offending IPs at the gateway.
• A SaaS product detects mass-assignment when a client posts 'role=admin'; the fix is explicit allow-listed create/update fields.
• An internal billing API moved from 'any authenticated' to BOLA checks and immediately killed a data-exposure class of tickets.

• Treat every token as a scope, not a pass: authorize per route and per object, always server-side.
• Use schema validation (OpenAPI-backed mocks, request-validation middleware) to reject unexpected fields/types.
• Rate limit and quota per principal; alert on bursts that logically cannot happen (one user, 10k orders/min).
• Version your API, log request/response invariants, and keep the contract in version control with the code.

• Returning 'auth required' only on the UI route while the same data sits behind an unguarded /api/report.
• Doing object checks in the frontend (hide buttons) and letting the backend trust the 'role' field in the payload.
• No rate limit anywhere, because 'it's internal' — until the internal token leaks into a public script.
• Copying stack-based validation but skipping the authz middleware that is the actual control.

• Before blaming the gateway, run the same request twice with different principals (the differential test) to isolate authz.
• Check for a Swagger/OpenAPI stubbed endpoint on your own service — it often enumerates routes you forgot.
• When rate limits misbehave, verify the key you quoted against: IP vs token vs user gives very different curves.

• Only fuzz/scan APIs you own; an 'API scan' of a partner's services without scope is an illegal intrusion.
• Store tokens as hashes server-side where you don't need the raw secret, and rotate keys on a schedule.
• Make rate-limit configs part of the repo, not a secret — their absence is as reviewable as their presence.