API Security Best Practices: Authentication, Authorisation and the OWASP API Top 10
API security best practices: authentication, object and function authorisation, tokens, rate limits, validation, secrets, logging, inventory and lifecycle.
What are the most important API security practices?
Authenticate every caller, authorise every object and function on the server, use short-lived tokens, validate input and limit what responses expose, rate-limit by client and endpoint, keep secrets out of code, log and monitor access, keep an inventory of every API version, and treat third-party APIs as untrusted. The OWASP API Security Top 10 2023 is a good checklist of where APIs commonly fail, starting with broken object level authorisation.
This guide is for developers, architects and product owners building or buying APIs for web apps, mobile app backends, integrations and partners. It complements building a secure customer-facing web application and API integration for Australian businesses.
No API can be made perfectly secure. These practices reduce risk; testing and monitoring show whether they work.
Key takeaways
- Check, on the server, that the caller may access each specific object and function.
- Use OAuth 2.0 or OpenID Connect for user access; follow current OAuth security guidance.
- Return only the fields the client needs; never rely on clients to hide data.
- Rate-limit and set quotas by client, user and endpoint.
- Store secrets in a secrets manager; never in code, mobile apps or front-end bundles.
- Keep an inventory of APIs, versions and owners; retire old versions.
- Validate third-party API responses as untrusted input.
The OWASP API Security Top 10 (2023)
OWASP's API Security Top 10 2023 lists the most common API risk categories (OWASP):
| # | Risk | What it looks like |
|---|---|---|
| API1 | Broken Object Level Authorization | Changing an ID returns someone else's record |
| API2 | Broken Authentication | Weak token handling, credential stuffing, missing MFA for sensitive actions |
| API3 | Broken Object Property Level Authorization | Responses expose fields users should not see, or requests can set fields they should not change |
| API4 | Unrestricted Resource Consumption | No limits on requests, payload sizes or costly operations |
| API5 | Broken Function Level Authorization | Regular users can call admin functions |
| API6 | Unrestricted Access to Sensitive Business Flows | Automated abuse of purchasing, booking or sign-up flows |
| API7 | Server Side Request Forgery | The API fetches attacker-supplied URLs |
| API8 | Security Misconfiguration | Verbose errors, permissive CORS, missing TLS settings |
| API9 | Improper Inventory Management | Forgotten old versions or undocumented endpoints |
| API10 | Unsafe Consumption of APIs | Trusting third-party API data without validation |
Authentication and tokens
- Use OAuth 2.0 and OpenID Connect through a proven identity provider for user access; follow the OAuth 2.0 security best current practice (RFC 9700).
- Use the authorisation code flow with PKCE for browser and mobile clients; avoid flows that expose tokens in URLs.
- Keep access tokens short-lived and scoped; rotate refresh tokens and detect reuse.
- Validate tokens fully on every request: signature, issuer, audience, expiry and scopes.
- Never put secrets in mobile apps or single-page apps; they can be extracted.
- Authenticate service-to-service calls with client credentials, mutual TLS or workload identity.
- Protect login, password reset and token endpoints with rate limits and monitoring.
Authorisation: objects, properties and functions
Most serious API breaches are authorisation failures. Enforce three levels on the server:
- Object level: for every request that references an object, check that this caller may access this object (ownership, tenant, role).
- Property level: return only the fields the caller may see, using explicit response schemas; reject attempts to set fields the caller may not change (mass assignment).
- Function level: check the caller's role or permission for every operation, especially administrative and bulk actions.
- Centralise authorisation logic where possible so it is consistent, and test it with automated tests that try to access other users' and tenants' data.
- Unpredictable IDs help but are not a control; the check is the control.
Pro tip
Our recommendation: add an automated test for every endpoint that calls it as a different user or tenant and expects a refusal. These tests catch the most common and most damaging API bug class before it ships.
Input validation, output and errors
Validate requests against a schema: types, lengths, formats and allowed values. Reject unexpected fields. Use parameterised queries to prevent injection. Limit payload sizes and pagination. Return explicit response schemas so new database fields are not leaked by accident. Return generic error messages and log details privately; stack traces in responses help attackers. Configure CORS narrowly, only for origins that need it.
Rate limiting and abuse protection
Apply rate limits and quotas per client, user, IP and endpoint, with stricter limits on login, password reset, search, exports and costly operations, including AI calls. Protect sensitive business flows (bookings, purchases, account creation) against automation with limits, anomaly detection and, where appropriate, challenges. Limits protect cost and availability as well as security.
Secrets and dependencies
Store API keys, database credentials and signing keys in a secrets manager, give each the minimum permissions, rotate them, and scan repositories for leaks. Keep frameworks and libraries patched, pin versions and scan dependencies in CI; software supply chain failures are now third in the OWASP Top 10:2025 for web applications (OWASP).
Logging and monitoring
Log authentication events, authorisation failures, rate-limit hits, administrative actions and unusual access patterns, with request IDs that link across services. Do not log tokens, passwords or unnecessary personal information. Alert on spikes in authorisation failures, enumeration patterns and unusual data volumes. See application monitoring and observability.
Inventory and lifecycle
You cannot protect APIs you have forgotten. Maintain an inventory of every API, version, environment, owner and consumer, ideally generated from OpenAPI specifications. Version deliberately, publish deprecation timelines, monitor usage of old versions and remove them. Gateways help centralise some controls; see API gateways. For APIs used by AI agents, see APIs for AI agents. Keep test and staging APIs away from production data and off the public internet where possible.
Consuming third-party APIs safely
- Validate third-party responses as untrusted input.
- Use timeouts, retries with backoff and circuit breakers.
- Do not follow redirects or fetch URLs from responses without checks.
- Store their credentials securely with minimum scopes.
- Verify webhook signatures and handle replays; see webhook design.
- Monitor their availability and error rates.
Australian notes
If your APIs handle personal information and your business is covered by the Privacy Act, APP 11 requires reasonable steps to protect it, and a breach may trigger the Notifiable Data Breaches scheme. APIs that send data to services overseas raise APP 8 questions. See cyber incident response planning for the reporting side.
Common mistakes
- Checking that a user is signed in but not that they own the record.
- Returning full database objects and filtering in the client.
- Long-lived tokens with broad scopes.
- API keys in mobile apps or JavaScript bundles.
- Old API versions left running and unmonitored.
- Relying on a gateway for authorisation decisions it cannot make.
Sources
OWASP API Security Top 10 2023; OWASP Top 10:2025; RFC 9700, OAuth 2.0 security best current practice; OAIC, APP 11.
Checklists and tables are ours. Nothing here is a security certification or ZSpace client data.
Conclusion
API security comes down to a few disciplines applied everywhere: authenticate properly, authorise every object and function on the server, expose only what is needed, limit abuse, protect secrets, log what matters and know every API you run. Test authorisation automatically, monitor continuously and treat third-party APIs with the same suspicion as user input. For documenting your API for partners, see API documentation best practices. For protecting the keys themselves, see secrets management. For document and image uploads, see secure file uploads.
Building or reviewing APIs?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on secure APIs and integrations and mobile app backends. If it would help to review your authorisation design, we are happy to talk it through.
Common questions.
Broken object level authorisation, ranked first in the OWASP API Security Top 10 2023. It happens when an API returns or changes a record without checking that the caller is allowed to access that specific record, for example by changing an ID in the request. Every endpoint that takes an object identifier needs a server-side ownership or permission check.