APIs expose business logic directly, so weaknesses are reachable and repeatable. The controls that prevent most incidents are unglamorous and well understood.
Authenticate and authorise separately
Authentication proves who is calling. Authorisation decides what they may do. Checking the first and assuming the second is the single most common API flaw: a valid token used to read another customer record.
Check object ownership on every request that accepts an identifier, not only at the collection level.
Validate input strictly
- Accept only the fields you expect and reject the rest
- Validate types, ranges and formats server side
- Use parameterised queries everywhere without exception
- Treat file uploads as hostile until proven otherwise
Limit the blast radius
Rate limit per identity as well as per address. Scope tokens narrowly and expire them. Log authentication failures and privilege changes, and alert on unusual patterns rather than reviewing logs after an incident.
Do not leak in errors
Stack traces, SQL fragments and internal hostnames in error responses hand attackers a map. Return a generic message to the client and keep the detail in your own logs.
Transport and storage
Enforce TLS, set HSTS, hash passwords with a modern algorithm, and encrypt sensitive fields at rest. Review dependencies for known vulnerabilities on a schedule, not when something breaks.
Assume every identifier in a request will be changed to someone else's. If that returns data, you have a serious problem regardless of how strong your login is.
Where to start
Take one endpoint that accepts a record ID and try to read another account's data with a valid token. The result tells you whether your authorisation is real.
