API Penetration Testing Checklist: How to Test Auth, BOLA, Rate Limits, and Business Logic

Why API Pentesting Needs Its Own Methodology

Web application testing and API testing overlap, but they are not the same engagement.

APIs hide business logic in structured requests, background jobs, mobile clients, partner integrations, and service-to-service trust boundaries. The prettiest front end in the world tells you very little about whether the API underneath is safe.

That is why API penetration testing needs a checklist built around how APIs actually fail.

Step 1: Build a Real API Inventory

Before you test deeply, make sure you know what exists.

Include:

Public APIs
Internal APIs exposed to front ends or mobile apps
Partner and third-party integration endpoints
Admin and support APIs
Deprecated versions that still answer requests
GraphQL, REST, gRPC, and webhook surfaces

One of the most common problems in API reviews is not a clever exploit. It is shadow or forgotten endpoints that never made it into the formal inventory.

Step 2: Validate Authentication the Way Attackers See It

Review:

Token issuance and expiry
Refresh token rotation
Audience and issuer validation
Weak API key handling
OAuth scope enforcement
Session to API trust boundaries

Example:

An API gateway may validate a bearer token correctly while the downstream service fails to check scope or tenant context. The authentication story looks good on paper, but the real control breaks one hop later.

Step 3: Test Authorization at Three Levels

Object-level authorization

Can one user access another user's object by changing an identifier?

Function-level authorization

Can a lower-privileged user trigger an admin-only action through a hidden endpoint?

Property-level authorization

Can the caller read or update fields that should stay server-controlled?

This is where BOLA, broken function-level auth, and mass assignment findings usually appear.

Step 4: Stress Input Assumptions

Check:

Numeric and UUID identifier tampering
Nested JSON mutation
Unexpected enum values
Over-posting and under-posting of fields
File and multipart upload behavior
GraphQL query depth, batching, and introspection controls

Example:

An order update endpoint might reject a direct attempt to change a price field. But the same endpoint may accept a nested discount object or internal status flag that indirectly changes financial outcomes. That is still an authorization and business logic problem, not just an input validation bug.

Step 5: Test Abuse Controls

Review whether the API can be:

Enumerated without friction
Brute-forced on login or token endpoints
Flooded through search, export, or expensive GraphQL operations
Used to create resource exhaustion through asynchronous jobs

For sensitive endpoints, test:

Per-user limits
Per-IP limits
Per-tenant limits
Retry behavior
Lockout and cooldown handling

Step 6: Inspect Trust Boundaries and Integrations

The most interesting API flaws often sit where one system trusts another too much.

Look at:

Webhook validation
Internal-only headers that can be spoofed from the edge
Service-to-service tokens with broad scope
Job queues that accept user-controlled payloads
Partner APIs with overly permissive grants

API Pentest Checklist by Risk Area

Inventory and discovery

All active versions identified
Deprecated routes tested
Hidden GraphQL operations discovered
Admin and support endpoints included

Authentication

Token validation consistent across services
API keys scoped and rotated
OAuth grants limited to intended use
Refresh and revocation logic tested

Authorization

BOLA tested across multiple object types
Function-level auth checked for admin and support actions
Property-level auth tested for sensitive fields
Cross-tenant isolation validated

Input and schema handling

Nested object mutation tested
Mass assignment attempted
File upload and content-type edge cases explored
GraphQL query cost and batching reviewed

Abuse resistance

Login, registration, and reset flows rate limited
Export and search endpoints tested for high-volume abuse
Async jobs examined for queue amplification
Error messages reviewed for leakage

Observability

Authorization failures logged with useful context
Sensitive token events monitored
Alerting exists for suspicious enumeration or privilege misuse

A Simple Example: BOLA That Hides Behind Clean UI Logic

Suppose a customer success tool has an endpoint that returns account notes.

The UI only shows notes for accounts assigned to the logged-in user, so everything appears fine. But the API accepts an account_id parameter and only checks whether the caller is authenticated, not whether they are assigned to that account.

That flaw will never show up in design mockups. It appears only when someone tests the API directly, with multiple users, and changes identifiers on purpose.

What a Good API Pentest Report Should Include

Full tested endpoint set and assumptions
Role matrix used during testing
Findings mapped to exploit scenarios, not just categories
Reproduction requests and business impact explanation
Root-cause remediation guidance
Retest recommendation for high-risk fixes

Good reports teach engineering something about the system. Weak reports just label it.