By Garrett Kohlrusch | GK Data LLC
An API can require a valid token on every request and still expose another customer’s data, an administrative function, or a business workflow that was never meant to be automated. Authentication tells the server who sent the request. It does not prove that the caller should be allowed to perform the requested action.
That gap is why effective API security testing follows roles, objects, properties, and state changes instead of stopping at endpoint discovery.
The real attack surface is the authorization model
Consider an endpoint such as GET /api/invoices/1842. A valid token may be required, but the server still has to answer several questions:
- Does this user belong to the organization that owns invoice 1842?
- Does the user’s role permit invoice access?
- Which invoice properties may this role read or change?
- Can the same request be replayed after a role or account change?
- Does a related export, mobile, legacy, or GraphQL endpoint enforce the same decision?
If the application trusts an object identifier supplied by the client without checking ownership, a normal user may be able to substitute another identifier and retrieve or modify someone else’s resource. OWASP lists this class as API1:2023 Broken Object Level Authorization.
Four authorization layers to test
Object-level authorization
Can User A access User B’s record by changing an ID, UUID, filename, nested resource, or GraphQL variable? Testing needs at least two controlled accounts so the result can be distinguished from a normal access path.
Property-level authorization
Can the caller read fields that should be hidden or submit properties the interface never offered? The current OWASP model groups excessive data exposure and mass-assignment-style behavior under Broken Object Property Level Authorization.
Function-level authorization
Can a standard user call an administrative route, change the HTTP method, or reach an older version of a privileged function? Hiding a button in the interface does not enforce authorization on the server.
Business-flow authorization
Can a valid sequence be repeated, reordered, or automated in a way that violates the business rule? Examples include reusing a one-time discount, skipping an approval, reserving inventory at scale, or changing a transaction after its expected final state.
Authentication and session behavior still matter
API assessments also examine how tokens are issued, scoped, refreshed, revoked, and accepted. Important questions include:
- Can expired, logged-out, or downgraded sessions continue to call sensitive endpoints?
- Are reset, invitation, and verification tokens single-use and bound to the correct account?
- Does the server validate token audience, issuer, signature, and intended purpose?
- Can a mobile or legacy client obtain broader permissions than the current web client?
- Are rate limits and abuse controls applied to sensitive operations, not only login?
Inventory is a security control
Teams cannot protect endpoints they no longer remember. Mobile applications, old API versions, partner integrations, staging systems, generated documentation, and third-party webhooks can all expose behavior outside the primary interface. OWASP includes improper inventory management and unsafe consumption of third-party APIs in its current API Security Top 10.
AI-assisted reconnaissance is useful here. It can help correlate routes, parameters, JavaScript references, schemas, and observed responses across a large surface. It does not decide whether access is unauthorized. That requires controlled accounts, careful state management, and manual reproduction.
What manual API testing looks like
- Map the application. Identify hosts, versions, routes, schemas, clients, roles, and important data objects.
- Build a role and object matrix. Define what each controlled identity should be able to read, create, change, approve, or delete.
- Replay and vary legitimate requests. Change identifiers, properties, methods, sequence, tokens, and client context one variable at a time.
- Validate impact. Confirm the unauthorized outcome without collecting more production data than the proof requires.
- Retest the fix. Verify the corrected server-side decision across equivalent routes and roles.
Preparing for an API assessment
The most useful engagement starts with an authorized scope, test accounts for relevant roles, a description of sensitive workflows, and agreed safeguards for production data. Documentation and source access can improve efficiency when available, but the deployed behavior still needs independent validation.
GK Data scopes testing around the application rather than treating the OWASP list as a checkbox exercise. The deliverable ties each confirmed finding to a request, affected role, business impact, and practical remediation path.
See Web Application and API Penetration Testing or send the API type, environment, roles, and timeline to begin scoping.