API Security: Authorization and Abuse Tests for Production

Review production API security with a multi-tenant authorization example, token-validation checks, input and resource controls, and negative tests.

Start with the requests the server must refuse

A production API needs to establish the caller, authorize the action on the specific resource, restrict readable and writable fields, and bound the work a request can trigger. A valid login, gateway or web application firewall does not establish all of those conditions.

The fastest useful review starts with a sensitive endpoint and negative tests: another tenant's identifier, an insufficient role, an unexpected property, an invalid token and an expensive request. Verify both the response and the absence of an unauthorized side effect.

This article develops that approach for a hypothetical multi-tenant document API. It is an engineering review guide, not a complete security assessment or a claim that passing these checks certifies an application.

Separate identity, delegated access and token format

Authentication establishes a caller's identity. Authorization decides what that caller may do. OAuth supports delegated access; OpenID Connect adds an identity layer for end-user authentication. A JWT is a token format, not an authentication or authorization policy. See the OpenID Connect core specification.

For an application using OAuth authorization-code flows, implement the provider-supported flow with PKCE and transaction binding. The OAuth security best current practice, RFC 9700, requires PKCE for public clients and recommends it for confidential clients. Choose a supported library and verify the complete provider configuration rather than assembling a flow from snippets.

At the API boundary, validate the access token for this resource server. Do not accept an ID token as a substitute simply because both tokens are signed JWTs.

For signed JWT access tokens, the validation policy should establish:

An explicitly trusted issuer and keys obtained through that issuer's trusted configuration.
An allowed signing algorithm and a valid signature.
The intended API audience, required token type and claims for the chosen token profile.
Valid time constraints, including expiration and not-before when present.
A valid subject and the scopes required for the requested operation.

Decoding a JWT is not validation. Do not select an arbitrary key URL from untrusted token content. These checks follow the trust and substitution boundaries described in RFC 8725, JWT best current practices.

Opaque tokens need the authorization server's supported validation mechanism instead of JWT parsing. API keys need defined scopes, secure storage and rotation; they do not by themselves establish an end user's identity. For either model, test key rotation, disabled credentials and the effect of a lost validation dependency. Protected actions should not become public when validation fails.

Token expiry alone may not meet the required revocation speed. Decide how account suspension or a role change affects existing sessions and cached permissions, then test that policy.

Worked example: authorize one document, not just the endpoint

Suppose a project-management service exposes GET /documents/{id}, PATCH /documents/{id} and a document-export operation.

The hypothetical policy is:

A user must be an active member of the document's tenant.
A reader must also have access to the document's project.
An editor can change approved content fields within an accessible project.
Only a designated administrative operation can change ownership or access policy.
Exports include only documents and fields the caller may read.

A general documents:read scope is necessary in this design, but insufficient. It permits a class of operation, not every document in the database.

Resolve the principal from validated credentials. Establish tenant membership from authoritative application data or trusted claims under a defined freshness policy. Treat a tenant identifier in a URL, header or request body as a requested scope to verify, not proof of membership.

Load or query the resource within that authorized scope, then apply the project and action policy. For writes, ensure the authorization decision remains valid when the mutation commits, for example through a scoped conditional update and appropriate transaction handling. A permission check followed by an unrelated unrestricted update can leave a race.

Using a UUID does not remove this requirement. OWASP's broken object-level authorization guidance covers authorization regardless of identifier format.

Specify negative tests with observable outcomes

| Test in the hypothetical document API | Required outcome | What to inspect beyond the status | |---|---|---| | Reader requests an accessible document | Return only permitted fields | Response schema and absence of internal notes | | Reader requests another project without access | Deny under the documented policy | No document contents or revealing error details | | User substitutes another tenant's document ID | Deny under the documented policy | No cross-tenant read, cache hit or audit-data exposure | | Reader attempts a content update | Deny the write | Database state remains unchanged | | Editor submits an ownership or tenant change | Reject the disallowed property change | Ownership and tenant remain unchanged | | Client presents an expired or wrong-audience token | Reject authentication for this API | Handler does not perform the protected operation | | User requests a bulk export | Enforce the same resource and field policy for every item | Export artifact and download authorization |

Use consistent error semantics. An API can use 403 for forbidden access or deliberately conceal resource existence with 404; the choice must fit its contract and disclosure policy. Testing only the status is inadequate if a response body, timing difference, export file or log endpoint still reveals the resource.

Run these cases with at least two tenants and different roles. Include list, search, batch, export and older API versions. Authorization that works on the single-record route can be absent from a secondary access path.

Control properties in both directions

A document reader may be allowed to see title and content but not internal review notes. An editor may update content but not tenant_id, owner_id or access_policy.

Define separate response projections and writable-field schemas. Do not serialize a database object wholesale or copy arbitrary request properties into a persistence object. Schema validation helps enforce structure, but an allowed field can still require a permission check.

This is the distinction covered by OWASP's object-property authorization guidance. A successful object-level access check does not authorize every property.

Test nested properties too. A protected value hidden inside a metadata object should not bypass the update policy. Keep unknown-field behavior explicit so clients can distinguish a rejected update from an ignored field.

Validate input without confusing validation with injection protection

Validate types, ranges, formats, body size and supported content types at a defined boundary. Validate again where business rules require it, such as whether a document can enter a particular workflow state.

Bind database values through parameterized queries. An ORM is not a blanket defense if raw queries or expression strings concatenate untrusted input. Where a client selects a sort column or another SQL identifier, map it to a fixed allowed expression; value placeholders do not generally substitute SQL identifiers. See OWASP's SQL injection prevention guidance.

An OpenAPI document does not automatically enforce its schema. Confirm that the deployed validation middleware covers the route and test malformed requests against the running service.

For APIs that fetch user-supplied URLs, review server-side request forgery separately. Restrict allowed destinations and protocols, account for resolution and redirects, and enforce network egress restrictions. A URL-format check alone is not a network access policy. OWASP's SSRF guidance describes this additional boundary.

For browser sessions using automatically attached cookies, include CSRF defenses appropriate to the application. Do not treat CORS as authentication or as a complete CSRF defense. Use the OWASP CSRF prevention guidance when designing that flow.

Bound resource use by the work a request can create

A per-IP request counter alone does not protect an expensive export, a large batch or a request that triggers paid downstream calls. Shared networks also make IP-only limits a poor representation of a customer entitlement.

For the document example, define:

| Operation | Resource to bound | Failure behavior to verify | |---|---|---| | List and search | Page size, allowed filters, query duration and concurrent work | Reject invalid limits and stop work when its execution budget expires | | Export | Rows, output size, concurrent jobs and retained artifacts | Do not enqueue unbounded work or leave public download links | | Upload | Body size, file type policy, processing budget and storage quota | Reject oversized input before expensive downstream processing | | Downstream integration | Calls, retries, concurrency and spending exposure | Bound retries and stop new work when its budget is exhausted |

Choose limits through capacity testing and product requirements. Publish the consumer-facing limits and retry behavior; keep internal protective controls where disclosing exact values would create unnecessary exposure.

OWASP's resource-consumption guidance addresses limits beyond request frequency. Application throttling is one layer, not a promise of protection from every denial-of-service attack. Edge capacity, infrastructure controls and an operational response still matter.

Verify that deployed paths enforce the policy

A gateway can reject malformed credentials or excessive traffic, while the application enforces resource-specific rules. Identify which component owns each check and ensure no alternate origin, legacy route or internal endpoint bypasses the required boundary.

Use encrypted transport with a maintained TLS configuration and verified certificates on relevant hops. If a trusted proxy supplies identity headers, strip client-supplied versions and prevent direct access that would let a caller impersonate that proxy. Network location alone should not grant document access.

Record request identifiers, authorization outcomes, safe resource references and control failures. Exclude access tokens, API keys and unnecessary document contents. Review log access and retention, and test that a denied request is investigable without leaking the data it was meant to protect.

Keep an inventory of deployed versions, administrative routes, dependencies and service identities. A route absent from public documentation can still be reachable. Contract tests and dependency scanning cover different risks; neither substitutes for reviewing the deployed attack surface.

Turn the review into a release decision

For one sensitive endpoint, collect the following evidence before expanding its use:

The principal, tenant, object, action and property policy.
Passing cross-tenant, cross-role and invalid-token tests.
Database or downstream readback proving denied writes had no effect.
Runtime schema validation and parameter-binding evidence.
Capacity and abuse tests for expensive operations.
A check for gateway bypasses and forgotten versions.
Logs that support investigation without retaining credentials or unnecessary content.
An owner and containment procedure for a confirmed failure.

These are a focused starting point. File handling, webhooks, browser security, third-party integrations and regulated data may require additional threat-specific assessment.

Start with the endpoint that can expose the most sensitive data or perform the most consequential write. Fix its failed boundaries, then apply the same policy and tests to its alternate access paths.

For implementation work, see Ampity's backend systems and API service. For a broader review of infrastructure controls and evidence, see cloud security and compliance. The scope and acceptance criteria should state what will be tested, not promise that an API is comprehensively secure.