API Security: Authorisation, Rate Limits, and Safe Integrations

A secure API checks more than whether a request has a valid token. It must establish what the caller may do to the specific resource, validate the request, and limit expensive operations. These controls belong on the server and should remain effective when someone bypasses the user interface or calls the endpoint directly.

Authorise the object and the action

Authentication establishes identity. Authorisation checks the requested operation against the account, role, tenant, and resource. A valid user ID does not automatically grant access to an invoice ID provided in the URL. Apply consistent checks in shared service code so background jobs and new endpoints do not bypass them.

Test horizontal access between users and vertical access between roles. Include nested resources and bulk operations. When a user can update an object, validate which fields they may change; accepting an entire client payload can expose administrative fields that the interface never displays.

Control resource consumption

Apply request size limits, pagination, timeouts, and bounds on expensive queries. Rate limits should reflect the operation: sign-in, search, file conversion, and report generation have different cost and abuse profiles. Consider account and tenant limits as well as IP-based controls.

Keep limits understandable for legitimate users and integrations. Return actionable errors and define retry behaviour. For distributed systems, ensure the limit is enforced consistently across instances. Queue expensive work when appropriate, and make job status access subject to the same permissions as the original request.

Validate integrations and failure paths

Use explicit schemas and reject unexpected fields where appropriate. Treat upstream data as untrusted. Validate webhook signatures against the original payload, protect against replay according to the provider's mechanism, and deduplicate events before changing state.

Return useful errors without exposing stack traces, secrets, or unnecessary record details. Record request identifiers for investigation. Exercise unavailable dependencies, malformed payloads, expired sessions, and repeated submissions. Security and reliability often meet at these boundaries, where a retry or error can accidentally change access or duplicate an action.

What to follow before development

• Write permission rules for each endpoint and resource type.
• Test cross-user, cross-role, and cross-tenant requests.
• Bound payload sizes, query complexity, and expensive work.
• Verify signatures, retries, and redacted error responses.

A practical example

A report endpoint checks that the user is signed in but accepts any tenant ID. The fix derives authorised tenant access from the server session, applies it inside the query, and checks report download permissions again. A queue prevents repeated export requests from exhausting the application's resources.

Sources and further reading

• OWASP API Security Project
• Stripe webhook delivery documentation

Plan your next step

Turn your priorities into a scoped engineering plan with our web app development team. For a related implementation guide, read multi-tenant isolation.