API security: authentication, limits and data protection

01Inventory interfaces, data and ownership

Start with the interfaces that are actually reachable. OWASP identifies incomplete inventory as a risk, particularly forgotten versions and test environments. Record the owner, purpose, clients, data types and retirement plan for each interface. Publishing documentation for a new version does not make the old endpoint disappear.

Include exports, administration, webhooks, batch imports and background jobs. Identify who supplies data, who receives it and when a paid operation occurs. Separate responsibility for an external service from responsibility for your use of it. An overprivileged credential remains your risk even when the supplier’s service behaves correctly.

The output should be a short map and explicit decisions, rather than just URLs. Who can restore access, approve an export or disable a problematic integration? Without those answers, protection is difficult to operate. Prioritise interfaces that can expose other customers’ information or make significant changes.

02Authentication and authorisation answer different questions

Authentication verifies a presented identity or credential. Authorisation determines what that principal may do. OWASP recommends least privilege, denial by default and checks on every request. A signed-in account is therefore not automatically entitled to every invoice or administrative function.

Make the decision on the server. A hidden button or frontend filter only changes the interface; another client can call the same operation. Express policy in business terms: an accountant may read invoices for assigned branches but cannot change a supplier’s bank account. That is more precise than saying the user “has system access”.

03Choose credentials for the type of client

Distinguish a person using an application from one service calling another. OAuth 2.0 supports delegated access; OpenID Connect adds end-user authentication on top. For an authorisation code flow, follow RFC 9700, including PKCE for public clients. Avoid designing a custom sign-in protocol to shorten implementation.

An API key can identify an integration without identifying an individual person, role or organisation. Give each integration its own access and necessary scope. A secret embedded in public JavaScript or a distributed mobile application cannot be treated as a confidential server credential. The architecture must account for where the client actually runs.

JWT is a token format, not a complete security solution. Following IETF JWT guidance, verify cryptographic operations, the trusted issuer and intended audience; also enforce time validity under the applicable profile. A signed token is not automatically encrypted. Do not substitute a sign-in ID token for an API access token.

04Check permission for every record

Broken Object Level Authorization means missing or incorrect access checks for specific objects. Replacing sequential identifiers with UUIDs does not fix it. The server must establish whether the verified principal can act on the requested record, including reading, changing, deleting and exporting it.

Consider a fictional system holding invoices for companies A and B. Company A’s accountant may read selected invoices belonging to A. A test using the correct token and an allowed A invoice can succeed. The same account requesting a B invoice must be refused without exposing its content. This is an expected test outcome, not a claim about a vulnerability we found on a real website.

Policy may also depend on a branch, project assignment or document state. Matching a user identifier alone can therefore be insufficient. Apply the same policy to detail views, lists, search and batch operations. Protecting the detail endpoint while exporting every row leaves the access boundary open.

05Keep organisations separate in caches and jobs

In a shared business application, a tenant represents a separate customer organisation. OWASP describes tenant isolation across data, caching and processing. A tenant identifier supplied in a request is not proof of membership. Verify its relationship to the authenticated principal and carry that context safely into subsequent work.

An invoice cache must distinguish all factors affecting its content or permissions, such as tenant and user scope. A separate cache key does not replace authorisation. Queues matter too: a job created for company A must not execute in company B’s context. Include files, search indexes and download links in the review.

Decide what happens when membership is removed or a role changes while a job is waiting. Sensitive operations may require current permission checks at execution and when the result is downloaded. Separate databases can strengthen isolation, but cannot correct an application selecting the wrong customer. Each layer needs appropriate verification.

06Allow specific fields and business operations

OWASP also distinguishes property-level authorisation. An API should not automatically return an entire database record or persist every field of an incoming object. Define permitted input and output properties for each operation. Syntactically valid JSON can still request a change the caller has no right to make.

For an illustrative profile, name and phone updates may be allowed while administrator status and account approval require a separate process. A customer might see an invoice amount and due date without access to an internal note. Removing that field only in the frontend does not protect it: once the server sends it, the client already has it.

Check process state as well. Permission to create a draft need not include permission to approve it, and a paid document may not allow the same edits as a draft. Rules must hold across HTTP methods, batch interfaces and API versions. Handle important state transitions explicitly and atomically according to the business requirements.

07Separate rate limits from quotas

Distinguish request rate, concurrent work and total consumption. A rate limit usually controls pace within a defined time window. Here, quota means an allocated volume over a longer period or a budget. Supplier terminology varies, so document the actual rule, unit, owner and behaviour when the allowance is exhausted.

RFC 6585 defines status 429 for too many requests; the response may include Retry-After. Clients need bounded retries with delays so they do not amplify the problem. An IP-only limit can group unrelated customers behind one network. In a distributed API, check that separate instance allowances do not exceed the intended shared limit in aggregate.

08Control the cost of a single request

OWASP API4 covers paid external operations as well as CPU and memory. One request can send many messages or create a large export. Complement request counts with item limits, processing deadlines, pagination and limits on subsequent work. Expensive operations need their own policy.

Before starting paid work, reserve the necessary capacity or budget in a way that remains correct under concurrency. Simply reading a balance and deducting later can let several requests consume the same allowance. Define what gets released after failure and which costs have already occurred. Customers should be able to distinguish waiting, rejection and completion.

Review limits alongside database and API performance. A client timeout does not guarantee that server work stops. Monitor queues and downstream services too. Idempotent processing can reduce duplicate effects from retries, but its keys need the correct client and operation scope. Idempotency does not replace permission checks.

09Give credentials an owner and a complete lifecycle

OWASP Secrets Management distinguishes creation, rotation, revocation and expiry. Record each credential’s purpose, owner, permissions and environment. Production and testing should not share one key. Supply secrets to applications through a controlled mechanism, rather than placing them in documentation, repositories or routine logs.

Planned rotation may use a short, controlled overlap between old and new credentials. Confirm that clients have migrated, then revoke the old access. When compromise is suspected, limiting misuse takes priority: do not keep the compromised key active simply for migration convenience. Prepare the process before an incident makes improvisation necessary.

A short token lifetime limits the exposure window, but does not necessarily provide immediate revocation. Decide how to stop already-issued access and how quickly that decision reaches every service. The solution depends on token type and infrastructure. Creating a replacement secret is insufficient if the old one remains accepted.

10Validate inputs, outputs and external events

OWASP REST Security recommends HTTPS, input validation and careful handling of sensitive data. Check types, ranges, allowed methods and input size. CORS is a browser rule, not authorisation for server clients. Cookie-based authentication needs appropriate CSRF protection. Choose controls according to the actual interaction flow.

A webhook needs origin verification and correct event handling. For example, Stripe documents signatures, retries and duplicate events. Apply the supplier’s recommended verification to the correct data, check the time context and prevent repeated business effects. A valid signature does not prove that an event belongs to the right customer or may modify any order.

If the API downloads a file from a client-supplied address, assess SSRF risk. Restrict destinations and outbound access, including redirects and internal services. Even a trusted partner’s response is input requiring validation and reasonable limits. An integration should not automatically trust everything that its supplier returns.

11Explain events in logs without creating another leak

OWASP Logging recommends recording significant security events and protecting the records themselves. Investigations generally need a timestamp, request identifier, principal, tenant, operation and outcome. Do not record full tokens, passwords or complete request bodies simply because doing so is convenient. Limit sensitive content to a justified need.

Watch for repeated denied access across tenants, unusual exports and sudden growth in paid operations. Error counts alone may not distinguish an attack from a faulty client, so provide context and assign responsibility for investigation. An alert without a recipient and response process is just another message. Test what happens if log collection fails.

The incident process should restrict affected access, preserve evidence and establish impact. Stopping the entire API may be unnecessary if a specific integration can be disabled safely. Equally, do not promise continuity at any cost. Assess any notification duties against the actual event and applicable requirements.

12Accept verified scenarios, not a technology list

Before handover, prepare test accounts with genuinely different roles and tenants, using non-production data. Define the expected outcome, environment and evidence for each scenario. Successful access for the right user is only part of the test. Also demonstrate refusal of prohibited operations without side effects or sensitive disclosure.

• A company A account cannot obtain details, lists or exports of company B’s private data.
• A read-only role cannot write, and an ordinary profile update cannot grant administrator status.
• Invalid, expired or revoked access fails under the defined policy.
• Limits hold under concurrency, multiple keys and multiple service instances.
• A duplicate event does not apply the same business change again.
• Logs explain the decision without containing access secrets.
• Relevant tests repeat after role changes, new versions and export modifications.

Connect each finding to a specific repair and retest. An API security audit can examine important boundaries, while operational ownership remains ongoing team work. Define scope, tested roles, review limitations and the repair plan. Purchasing a gateway or library is not acceptance evidence by itself.

13Frequently asked questions

14Sources and a practical next step

OWASP API Security Top 10 is a risk overview, not a certificate or complete acceptance checklist. Primary IETF specifications and documentation linked beside individual claims provide further detail. The invoice example, review checklist and allocation of operational responsibilities are editorial suggestions to adapt to your project.

Begin with one sensitive action, such as an invoice export. Document identity, tenant, action, data, cost and failure behaviour. Turn those decisions into a verifiable scenario and assign an owner, then extend the approach to other interfaces. This article contains no measured vulnerability findings or assurance about a specific application.