Before opening an API to the public, check authentication, object level authorisation, rate limits, input size limits, error messages, logging, key handling, version retirement and your endpoint inventory. Most real world API breaches come from broken authorisation and forgotten endpoints, so spend the most time there.
Identity and authorisation
- Every endpoint requires authentication unless you can name why it does not. Keep a short list of public endpoints and review it.
- Authorisation is checked on every object. If a request asks for record 1042, the server checks that this caller may see record 1042. Test by logging in as user A and requesting user B's identifiers.
- Function level checks exist. Administrative routes reject ordinary users even if the user guesses the path.
- Tokens expire and can be revoked. Short lifetimes for access tokens, and a clear way to cut off a leaked key.
Abuse and input
- Rate limits per key and per address, with tighter limits on login, password reset, search and anything that costs money to run.
- Size and shape limits. Maximum body size, maximum page size, maximum nesting depth, and rejection of unknown fields where practical.
- Validate input on the server. Types, ranges, allowed values. Do not rely on the client.
What the API says and records
- Error messages are plain and uniform. No stack traces, no internal host names, no hint whether a username exists.
- Logs record who called what, and the result. Do not log full tokens, passwords or personal data in the clear.
Keeping track
- An inventory of endpoints and versions. The ones that hurt are the old version still running, the test route left in production, and the undocumented admin path. Compare the documented API with what the gateway actually receives.
Test before you ship
Run a dynamic scan against a staging copy, and do a manual pass on authorisation, because scanners are weak at business logic. Share the specification with the testers so they cover everything.
Check cross origin settings. A permissive configuration that allows any origin together with credentials is a common mistake. Check transport settings: modern TLS only, redirect from plain HTTP, and secure cookies if the API uses them.
After launch
Watch for spikes in errors, in one key's volume, and in requests for sequential identifiers. Plan version retirement before you need it, with dates communicated to users.
Safeguard offers API security scanning and dependency scanning; the demo below shows a scan flow.
Click through it at your own pace, or open it full screen.
Quick check
Is an API gateway enough?
A gateway helps with authentication, limits and logging. It cannot know whether user A may see record 1042. That check lives in your application.
Should the first version be small?
Yes. Every endpoint you do not ship is an endpoint you do not have to defend.
Last reviewed: 19 October 2026.
