An API exposes functions and data to programs. Poorly protected, it can leak information, accept unauthorized actions, or collapse under a flood of requests.
These practices apply regardless of the language you use.
Check who's calling, and what they're allowed to do
Authentication AND authorization. On every request: identify the caller (token), then verify their rights on the specific resource being accessed. Never assume an authenticated user is allowed to do everything or see another user's data.
Trust nothing that comes in
Strict validation. Check the type, format, size, and bounds of every parameter. Reject by default. Be wary of identifiers passed by the client — that's how direct access to someone else's object slips through.
Absorb the load
Rate limiting and quotas. Limit the number of requests per client, per key, and per route. Plan for quotas and clean behavior when limits are exceeded, to resist abuse and traffic spikes.
Protect transport and secrets
- HTTPS mandatory, TLS versions kept up to date.
- Keys and secrets kept out of code and the repository, stored in a vault or environment variables.
- Secret rotation and the ability to revoke them.
See, version, and shrink
- Log access and errors, monitor for anomalies, export to a SIEM.
- Version the API so it can evolve without breaking, and retire old versions.
- Only expose the endpoints you actually need; keep dependencies updated; test regularly (review, scanning).
Frequently Asked Questions
Is an API key enough to secure an API?
No. A key identifies, but doesn't authorize at a fine-grained level, and it can be stolen. You need authentication, per-resource authorization, and rate limiting.
Should error messages be detailed for clients?
Not in production — detailed errors give attackers useful information. Use a generic message on the client side and log the details server-side.
How do you prevent access to someone else's object?
Always verify the caller has rights to the specific identifier requested — never trust a client-supplied identifier without checking it.
Réagissez
Commentaires