API Security
API Security Testing: Finding BOLA, Broken Authorization, and Data Exposure
How to test tokens, object access, business workflows, and exposed data in modern APIs.
Why APIs need their own assessment. An API is the behind-the-scenes door a web site, mobile app, partner, or internal system uses to exchange data. A page can look secure while its API returns another customer’s records, accepts an unauthorised update, or trusts a token too broadly. API testing examines the request, response, identity, and server-side rule together.
The core question is access control. For every endpoint, the tester asks who is making the request, which object they are requesting, and whether they can perform this exact action. This identifies BOLA and BFLA issues: reading or changing an object or function outside the caller’s authority. Real testing uses multiple accounts, tenants, roles, and object states instead of only changing a number in a URL.
Technical coverage includes OAuth and JWT validation, expiry, refresh, scopes, audience, revoked sessions, mass assignment, schema validation, pagination, GraphQL, versioning, rate limits, excessive data exposure, and useful error handling. Workflow testing looks for requests that are valid HTTP but wrong for the business, such as approving before review, replaying a payment, or reopening a closed record.
Evidence and fixes. A finding captures the minimum request and response needed to reproduce the issue, with sensitive values masked. The safe pattern is to derive identity from the verified session, look up ownership on the server, validate every accepted field, and enforce state transitions centrally. Hidden buttons and hard-to-guess identifiers are interface details, not security controls.
After remediation, add automated authorization tests for each endpoint and role, log denied high-risk actions, keep an inventory of active APIs, and retest the original and neighbouring routes. This turns one assessment into durable API engineering practice.
Table of Contents
- Why APIs need focused testing
- Core controls
- Token example
- Risk and detection
- Remediation
Why APIs Need Focused Testing
APIs power web, mobile, partner, and AI experiences. Their attack surface often includes versioned endpoints, service-to-service identities, bulk exports, asynchronous jobs, and undocumented parameters that never appear in a browser interface.
Client → API gateway → authentication → authorization → service → data
Core API Security Controls
A focused assessment validates authentication strength, token lifetime and audience, object-level and function-level authorization, input schemas, rate controls, error handling, logs, inventory, and third-party exposure.
Retired endpoints must be disabled rather than merely removed from documentation. Each API version should enforce the same core controls.
Safe Token-Handling Example
A token issued for a customer portal should not automatically grant access to an internal administrative API. Each resource server should validate signature, issuer, expiry, audience, and scopes before applying its own authorization decision.
A token is evidence of authenticated context; it does not replace the object-level access check for a requested record.
Detection and Business Impact
High-risk failures can expose cross-tenant records, enable sensitive actions, or permit automated abuse at scale. Monitor repeated denied object requests, unusual export volume, use of retired versions, and tokens used from unexpected contexts.
Remediation
- Authorize every endpoint, object, and business action.
- Use short-lived, audience-restricted tokens with minimum scopes.
- Validate requests against explicit schemas and reject unexpected fields.
- Apply rate, resource, and pagination limits appropriate to the workflow.
- Log actor, action, target, decision, and correlation ID without logging secrets.
Risk Rating
| Severity | Description |
|---|---|
| Critical | An API grants broad privileged access or enables large-scale compromise of customers or systems. |
| High | Cross-tenant data, sensitive records, or high-impact business actions can be accessed without authority. |
| Medium | Constrained workflow abuse, excessive data exposure, or limited unauthorized access is possible. |
| Low | A minor implementation issue has limited practical impact. |
API Security Testing Checklist
- Inventory includes endpoints, versions, owners, and data sensitivity.
- Resource servers validate tokens independently.
- Object and function authorization are manually tested.
- Schemas, limits, and errors are safe by default.
- Monitoring detects enumeration, abuse, and anomalous exports.