APIs expose application logic and data directly, which makes them an attractive target. The OWASP API Security Top 10 highlights the most common weaknesses; most come down to a handful of disciplines.
Authorise every object and function
The most frequent API flaw is broken object-level authorisation: a user changes an ID in a request and sees someone else’s data. Check permissions on every request for every object, not just at login. Apply the same rigour to administrative functions.
Authenticate properly
- Use established standards such as OAuth 2.0 and OpenID Connect.
- Prefer short-lived tokens and validate them fully.
- Never put secrets or tokens in URLs.
Return only what is needed
Avoid sending full objects to the client and filtering in the user interface. Define response schemas so sensitive fields are never exposed by accident.
Limit and validate
- Apply rate limits and quotas to prevent abuse and resource exhaustion.
- Validate input against strict schemas.
- Protect business flows such as sign-up or checkout from automated abuse.
Know your inventory
Old API versions and undocumented “shadow” endpoints are common entry points. Maintain an inventory with owners, retire outdated versions and document every endpoint with a specification such as OpenAPI.
Test and monitor
Include API security testing in CI/CD pipelines, and monitor production traffic for unusual patterns such as enumeration or spikes in errors.
Building API security into the development lifecycle
The essentials above are most effective when they are built into how APIs are designed, built and operated. These proven best practices help teams make API security routine.
- Design first. Define APIs with a specification such as OpenAPI, including authentication, authorisation rules and data schemas, and review the design for security before coding.
- Validate input and output. Enforce schemas at the gateway and in the application, rejecting unexpected fields and limiting payload sizes.
- Centralise authentication. Use a standard identity provider and tokens such as OAuth 2.0 rather than custom schemes.
- Log for detection. Record authentication failures, authorisation denials and unusual access patterns and send them to security monitoring.
- Test continuously. Include API-specific tests for broken object-level authorisation, injection and excessive data exposure in CI pipelines.
- Retire old versions. Deprecate and remove outdated API versions that may lack current controls.
Common mistakes to avoid
- Relying on obscurity, assuming undocumented APIs will not be discovered.
- Checking authorisation in the front end only.
- Returning full database objects and filtering in the client.
- Using long-lived API keys shared across many applications.
Frequently asked questions
Is an API gateway enough?
Gateways enforce authentication, rate limits and schemas, but object-level authorisation must still be implemented in the application.
How do we find shadow APIs?
Analyse gateway logs, network traffic and code repositories, and require all APIs to be registered in an inventory.
A 90-day action plan
Days 1 to 30: build an inventory of external and internal interfaces from gateway logs, code repositories and network traffic, and record owners and the information each one exposes.
Days 31 to 60: route public interfaces through a gateway, enforce schemas and rate limits, and fix authorisation weaknesses in the highest-risk endpoints.
Days 61 to 90: add automated security tests to pipelines, send security events to monitoring and retire outdated versions.
Questions to ask development teams
- How does each endpoint check that the caller may access the specific record requested?
- Which fields are returned, and are any unnecessary?
- How are tokens issued, validated and revoked?
- What limits prevent abuse such as scraping or credential stuffing?
- Which versions are still live, and when will older ones be retired?
Key terms explained
- BOLA: broken object-level authorisation, where users can access other users’ records.
- Rate limiting: restricting how many requests a client can make in a period.
- OAuth 2.0: a standard framework for delegated authorisation using tokens.
- Shadow endpoint: an interface running in production without being documented or managed.
- Schema validation: checking requests and responses against a defined structure.
The bottom line
Interfaces now carry much of an organisation’s most valuable information, making them a prime target for attackers. Strong object-level authorisation, standard authentication, minimal responses, rate limits, a complete inventory and continuous testing address the most common weaknesses. Build these controls into design and delivery rather than adding them at the end, and monitor production traffic for abuse. Consistent practices across teams make secure interfaces the default rather than the exception.
Further reading on API security
For authoritative, vendor-neutral guidance on API security, see the OWASP API Security Project. You can also browse our free whitepapers.
