APIs connect your applications, partners and data. Each open endpoint is a possible entry point, so security must be part of the design. This checklist covers the checks we review first in API work.
Authentication and authorization
- Check authorization on the server for every request. Never assume it from the client.
- Check access to each specific record, not only to each endpoint. Can user A open user B’s record by changing an ID?
- Give tokens a clear expiry and a refresh process. Tokens should not last forever.
Handle input with care
- Validate all input on the server, even when the app also checks it.
- Limit how often a client can call sensitive endpoints, such as sign-in, payments and search.
- Check uploaded files by their content, not only their file extension.
Keep secrets out of the code
Keep API keys and passwords in environment variables or a secrets manager. Never commit them to source control. Rotate them on a set schedule, and right away if you suspect a leak.
Log the events that matter
Log failed sign-ins, denied access and unusual request patterns, not only errors. A clear record makes an incident far easier to investigate. Companies in the UAE working on API security can see how we deliver it locally on our [custom web development in Dubai](/dubai/custom-web-development) page.
We illustrate API security with a documented example: see the [patient platform concept](/case-studies/healthcare). Related reading: [Building Secure Authentication Systems](/blog/building-secure-authentication-systems).
A quick review before each release
- Every endpoint has an authorization check.
- Every input is validated on the server.
- No secret appears in the code or in the logs.
Use this checklist as a starting point, then test your APIs against it regularly. If you need help with API design or integrations, read about our API development and integration service.
Authorization on every route
The most common API failures are not exotic. They are endpoints that check whether a user is signed in but not whether that user owns the record they are asking for. Enforce object-level authorization in the service layer, not only in the router, so a new endpoint cannot skip the check by accident.
Input validation and output discipline
Validate every input against a schema at the boundary, and reject unknown fields instead of silently ignoring them. Return only the fields a client needs. Serializing a whole database row by default is how internal flags and personal data leak into responses.
Rate limits, abuse and monitoring
Apply rate limits per user and per IP address, with stricter limits on sign-in, password reset and any endpoint that sends email or messages. Log authentication failures and authorization denials with enough context to investigate, but never log secrets or full tokens. Alert on unusual patterns, such as one account touching many records in a short period.
Dependencies and secrets
Keep dependencies current and watch their security advisories. Store secrets in a managed secret store, rotate them on a schedule, and make sure they never appear in client bundles or error messages. A key committed to a public repository is a routine incident, and it should be treated as one.
Sector context changes API security considerably, so see how we approach [finance software](/industries/finance).
