API Security Testing: How Attackers Abuse APIs and How to Test for It

Why APIs need their own test

A web page shows a button only to users who may press it. The API behind the page receives the request from anyone who sends it. Mobile apps, front ends and integrations call hundreds of endpoints, often in several versions at once, and each endpoint has to check authorization on the server by itself. When one endpoint skips the check, an attacker needs nothing more than a valid account and a changed ID.

Public cases show what missing checks and limits cost. In January 2024 an attacker offered data on about 15 million Trello accounts, collected through an API endpoint that answered lookups by email address without authentication. A few months later an attacker registered as a partner on a Dell portal and, by his own account, pulled 49 million customer records at 5,000 requests per minute for three weeks with no rate limit in the way.

The OWASP API Security Top 10 in practice

The OWASP API Security Top 10 (2023 edition, the current one at the time of writing) lists the risks that cause the most damage. Here is what each looks like and how we test for it.

API1: Broken object level authorization

The API returns or changes an object by its ID without checking that the object belongs to the caller.

GET /api/v1/orders/48213
Authorization: Bearer <token of user 1077>

200 OK   (an order that belongs to user 2310)

We call every endpoint that takes an object ID with two accounts of the same role and swap identifiers in paths, query strings, JSON bodies and headers, including IDs that are predictable or leaked by other endpoints.

API2: Broken authentication

Typical causes are login and password reset endpoints without rate limits, error messages that reveal which emails are registered, tokens that never expire, and JSON Web Tokens accepted with a weak signing key or with the signature algorithm set to none. We test credential stuffing resistance, token validation and every step of the reset flow.

API3: Broken object property level authorization

The API accepts fields the client should never set, or returns fields the client should never see.

PATCH /api/v1/users/me
{"name": "Anna", "role": "admin"}

200 OK   (the account is now an administrator)

We compare what each response contains with what the interface displays, and send every writable object back with extra fields such as role, balance, tenant and verification status.

API4: Unrestricted resource consumption

No limits on page size, upload size, query complexity or actions that cost money, such as sending SMS. The result ranges from an outage to a large bill. In agreed time windows we request oversized pages, send expensive queries and repeat paid actions to find where limits are missing.

API5: Broken function level authorization

A regular user calls an administrative function directly.

DELETE /api/v1/users/5521
Authorization: Bearer <token of a regular user>

204 No Content

Administrative endpoints are often visible in JavaScript bundles and mobile app code. We collect them and call each function with each role.

API6: Unrestricted access to sensitive business flows

The API lets a script do at scale what the business expects a person to do once: buy up limited stock, create thousands of accounts, redeem a promo code repeatedly. We look for race conditions on one-time actions (a coupon redeemed twice by parallel requests) and replay flows at volume to see what stops them.

API7: Server-side request forgery

A feature that fetches a URL on the user's behalf (webhooks, image import, PDF rendering) can be pointed at internal services or the cloud metadata endpoint.

POST /api/v1/import
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

We test every URL parameter against internal addresses, redirects and other notations of the same address (decimal, octal, IPv6). We also check that cloud instances require session-based metadata access: on AWS, IMDSv2 needs a token obtained with a PUT request, which a plain URL fetch cannot send, so it blocks the request above.

API8: Security misconfiguration

Permissive CORS, stack traces in error responses, debug endpoints left enabled, default credentials and missing security headers. We check CORS policy, error handling and exposed debug paths across every endpoint.

API9: Improper inventory management

Old versions stay online after a new one ships, staging APIs with production data are reachable from the internet, and endpoints exist that nobody documented. We build an inventory from mobile apps, web bundles, documentation, DNS records and archived URLs, and compare it with the list you gave us.

API10: Unsafe consumption of APIs

Your API trusts data from a partner or third-party API more than it trusts user input: it follows redirects blindly, skips validation or passes the data into queries. We test what happens when the upstream response is malformed or malicious.

Chains turn medium findings into critical ones

CVSS scores each flaw on its own, so individual API flaws often rate as medium. Combined, they can reach much further than any single score suggests. A typical chain:

1. A profile endpoint leaks other users' internal IDs.
2. An object-level authorization flaw lets the attacker read any account's settings with those IDs.
3. The same endpoint accepts a change of email address through mass assignment.
4. A password reset sent to the new address gives full account takeover.

Our reports show the chain as well as each link, because fixing one link (here, the authorization check) stops the whole attack.

GraphQL, gRPC and APIs behind AI features

• GraphQL: introspection left on in production, deeply nested queries that exhaust the server, batching that slips past login rate limits, and authorization written per resolver, where one resolver is easy to miss.
• gRPC and internal APIs: services that trust any caller inside the network. Once one service is compromised, everything it can call is exposed.
• AI agents and assistants: an agent that calls internal APIs for a user should hold exactly that user's permissions. Prompt injection can push an over-privileged agent into calling endpoints the user could never reach directly.

How an API test runs

1. Inventory. Your OpenAPI or Postman collections if you have them, plus endpoints we extract from mobile apps, web bundles and traffic.
2. Accounts. At least two users for each role, and two tenants for multi-tenant products, so cross-user and cross-tenant access can be tested.
3. Testing. Manual checks for every category above, using the OWASP API Security Top 10 and the Web Security Testing Guide, with automated fuzzing for coverage.
4. Report and retest. Each finding with the exact request and response, its impact and the fix, then a retest once the fix is deployed.

Controls that prevent the most common flaws

• Enforce authorization in one shared server-side layer for every object and every function, and add automated tests that call each endpoint as the wrong user.
• Return only the fields the client needs, and bind input through an explicit list of fields each role may change.
• Rate-limit by account, token and IP address, with tighter limits on login, password reset, one-time codes and anything that sends messages or costs money.
• Keep the API inventory in the deployment pipeline and retire old versions on a schedule.
• Keep secrets in a vault, out of mobile apps and front-end code, and scan repositories for leaked keys.

Jetlink tests web and mobile APIs as part of its penetration testing work. Our development team also builds web and mobile backends, and we write the fixes in our reports with that experience.