API guide
API security
APIs expose your business logic and data directly. The most common API breaches are not clever hacks; they are missing checks, such as letting a logged-in user read someone else's record by changing an ID in the URL.
Top riskBroken object-level authorisation
IdentityOAuth 2.0 / OpenID Connect
PartnersKeys plus mTLS
KnowEvery API you expose
The risks that matter most
Based on the OWASP API Security Top 10 (2023).
| Risk | What it looks like | Control |
|---|---|---|
| Broken object-level authorisation | Change /orders/1001 to /orders/1002 and see another customer's order | Check ownership of every object in the service, not only at the gateway |
| Broken authentication | Weak tokens, keys in URLs, no expiry | OAuth 2.0 / OIDC, short-lived tokens, mTLS for partners |
| Excessive data exposure | The API returns full records and the app hides fields | Return only the fields the caller needs |
| No rate limits | Scraping, brute force, cost spikes | Limits per caller at the gateway |
| Function-level authorisation | A normal user can call admin endpoints | Separate admin APIs and check roles on every endpoint |
| Improper inventory | Old versions and test APIs still exposed | An API catalogue, and retire old versions on a schedule |
Also essential
- Validate every input against the API contract.
- Log every call with caller identity, and alert on unusual patterns.
- Test APIs for these risks before release, not after.
- Keep secrets and keys out of code and front-end apps.
More API guides: API design and gateway · Monolith or microservices? · Event-driven integration · API FAQ · Use case: partner APIs
Untangling integrations, or opening APIs to partners?
Tell us which systems need to talk, who will call your APIs, and what breaks today. We will come back with a plain view of the right structure, what to change first, and what to leave alone.