A practical API security testing checklist built around identities, objects, properties, functions, business flows, controlled mutations, and reproducible evidence.
Alice opens an invoice in a web application. The browser sends:
1GET /v1/invoices/inv_2048 HTTP/1.1
2Host: api.example
3Authorization: Bearer alice-token
4Accept: application/jsonThe server returns Alice's invoice. Authentication works. Transport encryption works. The response schema is valid. None of those facts answer the most important security question: what happens if Alice asks for Bob's invoice?
API security testing becomes much clearer when it begins with authorization decisions instead of payload lists. Model who may access which object, property, function, and business flow. Then change one dimension and capture the resulting evidence.
The OWASP API Security Top 10 2023 separates broken object-level, property-level, and function-level authorization because they fail at different boundaries. This checklist turns those boundaries into executable tests.
Start with observed traffic, not only documentation.
Capture:
An OpenAPI document helps, but deployed behavior is the authority. The browser may call an endpoint that is absent from the schema. A mobile client may use an older version. A documented GET may sit beside an undocumented PATCH.
Build the inventory around user journeys. “Create invoice, approve invoice, pay invoice, export invoice” explains more than four unrelated paths because it preserves the business state between calls.
Authorization testing needs controlled differences.
Prepare at least:
The exact matrix depends on the application. A healthcare system may use patient, clinician, billing, and support roles. A collaboration product may use workspace owner, member, guest, and external collaborator. The goal is to know which combinations should be allowed before sending the test.
Do not discover object ownership by probing real customer identifiers. Create authorized fixtures or obtain them from the engagement owner.
Insecure direct object reference, usually shortened to IDOR, is common search language. For APIs, OWASP uses Broken Object Level Authorization, or BOLA. The problem is not that an identifier is guessable. The problem is that the server uses a client-supplied identifier without enforcing the actor's permission to that object.
Start with a valid baseline:
1GET /v1/invoices/inv_2048
2Authorization: Bearer alice-tokenConfirm that inv_2048 belongs to Alice. Then change only the object:
1GET /v1/invoices/inv_9901
2Authorization: Bearer alice-tokenwhere inv_9901 is a known Bob-owned fixture.
Check every place an object reference can appear:
A denial is expected, but interpret it carefully. A 404 may be deliberate object hiding. It may also mean the fixture never existed. A 200 may contain Alice's own object because the server ignored the changed identifier. Proof requires data or behavior tied to Bob's object.
An actor may be allowed to access an object but not every field on it.
For reads, compare responses by role:
For writes, add or alter properties that the normal client does not send:
1{
2 "display_name": "Alice",
3 "role": "admin",
4 "account_id": "acct_bob",
5 "credit_limit": 500000
6}Change one sensitive property at a time. Then retrieve the object through an independent path and verify whether the server persisted the unauthorized value. An echoed request body is not proof of a state change.
Also test partial updates, alternate content types, nested objects, array items, bulk operations, and default values. Property authorization often diverges between create, update, import, and administrative paths.
Function-level authorization asks whether the actor may invoke the operation at all.
Examples include:
DELETE, PATCH, or bulk endpoint.Do not assume the user interface defines the security boundary. Hiding a button does not prevent a direct API request. Test the server's decision with the lower-privilege identity while preserving the same endpoint, method, and required request shape.
Then test nearby method and path variations. A GET may enforce a role while POST does not. A singular endpoint may be protected while its bulk equivalent is not. Versioned paths may have different middleware.
Authorization tests are meaningful only when the server's identity decision is understood.
Check:
Keep authentication and authorization conclusions separate. If an expired token is accepted, that is an authentication or session problem. If a valid Alice token reads Bob's invoice, that is an authorization problem. One request can expose both, but the report should say which security decision failed.
The API Top 10 extends beyond identity checks. Test the rules that protect scarce resources and sensitive workflows.
For resource consumption:
For sensitive business flows:
A safe test proves the missing control with the smallest authorized action. It does not create the impact the control was meant to prevent.
APIs often accept URLs for imports, webhooks, previews, avatars, document conversion, or integrations. These features create a server-side request forgery surface.
Check:
Use engagement-controlled destinations and out-of-band endpoints. A callback proves that some server-side interaction occurred. It does not by itself prove access to cloud metadata, an internal service, or sensitive data. Match the evidence to the claim.
For every API penetration testing hypothesis, keep:
This is the minimum evidence chain for explaining why a result matters.
Build structured tests from captured application flows and retain both the original and modified exchanges. Record whether the relevant execution completed, failed, timed out, or produced no signal. A hypothesis can propose an authorization test, but only executed evidence can support a candidate.
Suppose Alice requests Bob's invoice and receives:
1{"job_id":"job_719","status":"queued"}That response is not yet evidence of unauthorized invoice access. The job may fail. It may produce Alice's invoice. It may be a generic placeholder.
Validation should ask:
Separate test-produced candidates from validation. Evaluate each candidate on its own evidence so an inconclusive result does not distort another test. Validation reduces unsupported findings, but a reviewer should still confirm high-impact issues and deployment-specific consequences.
Use this compact sequence:
An API security test is complete only when it proves which authorization or business invariant was exercised, what changed, what reached the server, and what evidence supports the result.
This article was reviewed on 2026-08-16 against the OWASP API Security Top 10 2023, the OWASP guidance for Broken Object Level Authorization, and the stable OWASP Web Security Testing Guide. The checklist was reviewed for identity, object, function, session, workflow, resource, upstream-trust, evidence, and validation coverage.
The review focused on authorized testing of externally observable HTTP APIs. It did not perform a new production API assessment.
This checklist is not exhaustive. GraphQL query authorization, WebSockets, gRPC, mobile application trust, cryptographic protocol review, source analysis, and infrastructure configuration can require specialized methods.
API behavior is application-specific. Accurate results depend on representative identities and fixtures, current sessions, safe scope, and evidence that can distinguish the intended security effect from ordinary application behavior.