API Security Testing

Why it matters

The API carries the data; the user interface only displays it. Hidden buttons and client-side validation protect nothing against a caller who talks to the API directly, and most callers do: mobile apps, partner integrations and other services. One missing ownership check exposes every customer's records to every other customer; one unlimited one-time password (OTP) endpoint lets a script try codes until one works. Defects like these turn into data breaches and fraud, not cosmetic bugs.

For the tester the good news is that most of these checks are variations of what you already do: change the token, change the id, read the raw response, repeat the request, compare two responses. They need no scanner and no exploit skills, and a functional tester who runs them for every new endpoint finds many of these defects long before a penetration test does.

The OWASP API Security Top 10 (2023) as a checklist

OWASP publishes a separate Top 10 for APIs because API risks differ from web-page risks: there is no browser to attack, but there are ids in every request, tokens instead of sessions and no screen to hide anything. The 2023 edition replaced the 2019 one and reorganised the list; two 2019 names are still used by many teams, "Excessive Data Exposure" (now part of API3) and "Lack of Resources & Rate Limiting" (now API4), so this lesson gives both names.

Read each entry as a question to ask about every endpoint, with a safe check you can run with your own test accounts in a test environment:

• API1:2023 Broken Object Level Authorization (BOLA): the API trusts an id from the client without checking that the caller may access that object. Check: the same request with another user's token.
• API2:2023 Broken Authentication: tokens and logins are weak or unlimited: tokens accepted after expiry or logout, unlimited password or OTP attempts, credentials in URLs. Check: missing, expired, revoked and tampered tokens; count the attempts allowed.
• API3:2023 Broken Object Property Level Authorization: the response carries properties the caller must not see (excessive data exposure) or the request may set properties it must not (mass assignment). Check: read the raw JSON against the contract; send an extra field.
• API4:2023 Unrestricted Resource Consumption: no limit on request rate, page size, upload size or operations that cost money such as SMS. Check: repeat quickly, ask for pageSize=50000, upload one byte over the maximum.
• API5:2023 Broken Function Level Authorization: a role can call another role's function. Check: a customer token on an admin endpoint, as in the lesson on API authorization testing.
• API6:2023 Unrestricted Access to Sensitive Business Flows: a flow that harms the business when automated (buying all stock, booking every slot, mass sign-ups) has no limit, no step-up check (an extra verification such as a CAPTCHA or a one-time code) and no review. Check: script the flow with one account and see whether anything slows it down.
• API7:2023 Server Side Request Forgery (SSRF): the server fetches a URL supplied by the client, such as a webhook or an image import, without an allow-list. Check: supply a capture URL you control (one that records every request it receives, such as a Webhook Tester URL) and confirm what the server fetches; ask the developer how private addresses are refused rather than probing them.
• API8:2023 Security Misconfiguration: verbose errors with stack traces, HTTP without TLS, CORS that allows any origin, unneeded methods, default settings. Check: one malformed request and the response headers.
• API9:2023 Improper Inventory Management: old versions and debug endpoints still answer; the OpenAPI document and the deployed API differ. Check: call /v1 after /v2 shipped; list what answers but is not documented.
• API10:2023 Unsafe Consumption of APIs: data from a partner API is trusted without validation, size limits or redirect checks. Check: mock the partner and return bad data.

Try it: OpenAPI → Test Cases Try it: Webhook Tester Try it: API Header Validator

BOLA and broken authentication: change the token, then the id

BOLA is the top risk because ids are everywhere in APIs and the check that the caller owns the object must be written for every one of them. The lesson on API authorization testing built the users × requests matrix; a security pass extends it to the ids the matrix usually misses: query strings such as ?accountId=, request bodies, headers, nested routes such as /parcels/7731/label.pdf, batch and export endpoints, and file downloads, which are often served by a different code path with no check at all. Always use two accounts of the same role, and stop at the first record that proves the defect: your job is to show that the check is missing, not to collect other people's data.

Broken authentication in an API is mostly about tokens and the endpoints around login. For every protected endpoint send the request four ways and expect 401 each time, with a WWW-Authenticate header as in the lesson on API authentication and no data or internal detail in the body: no token, an expired token, a token from a session that has logged out, and a token with one character of the signature changed. Then look at the endpoints that issue credentials:

• Password, OTP and password-reset verification: count the wrong attempts the API accepts before a 429 or a lockout. A six-digit OTP has one million possible values; with no limit, guessing is a matter of time.
• JWTs: the header must not be accepted with "alg": "none", and a token issued for another audience, or by an issuer the API does not trust, must be refused; RFC 8725 (JWT Best Current Practices) sets out these checks. The JWT Header Analyzer and JWT Claims Analyzer show what a token claims before you test what the API does with it.
• Error bodies: "wrong password" and "no such account" must read the same, or the login endpoint confirms which accounts exist.
• Credentials and tokens never belong in URLs, logs or error messages; a token in a query string ends up in every proxy log.

# One protected request, four ways.
# Expected: 401 each time, with WWW-Authenticate and no data in the body
GET /v1/users/me HTTP/1.1
Host: api.example.test
# 1. no Authorization header
# 2. Authorization: Bearer <expired token>
# 3. Authorization: Bearer <token of a session that has logged out>
# 4. Authorization: Bearer <valid token with one signature character changed>

# OTP verification: send code 000001, then 000002, 000003 ...
# Expected: 429 or a lockout after a small number of attempts
POST /v1/auth/otp/verify HTTP/1.1
Host: api.example.test
Content-Type: application/json

{"phone": "+9665XXXXXXXX", "code": "000001"}

Try it: API Authentication Tester Try it: JWT Header Analyzer Try it: JWT Claims Analyzer

Excessive data exposure and missing rate limits

Excessive data exposure happens when the API returns the whole object and relies on the client to show only part of it. The profile screen shows a name and an avatar; the raw response also carries the e-mail address, the phone number, the national id, internal notes or a password hash. The 2023 edition folds this risk together with mass assignment into API3, because both are the same missing question: may this caller see, or set, this property? Test the read side by comparing every raw response with the contract, as in the lesson on API schema validation, and asking for each field whether this role needs it. Test the write side by adding a property the caller must not control, "role": "admin", "balance": 9999 or "verified": true, to an otherwise valid PATCH or POST, then reading the object back: the correct outcomes are 400, or the field silently ignored and unchanged.

Rate limits protect the resources every request consumes: CPU, memory, bandwidth, database connections and money, when an endpoint sends an SMS or calls a paid service. Without them one client can exhaust the service for everyone or run the guessing attacks above. RFC 6585 defines 429 Too Many Requests for this and says the response may carry a Retry-After header. A safe test has three parts and one place:

• Rate: send the same request quickly, with numbers agreed with the team, and record the request number at which the first 429 appears, the headers it carries, and whether the limit is per user, per API key or per IP address, since a limit only per IP restarts when the client changes address.
• Size: request ?pageSize=50000, send a body or upload one byte over the documented maximum, and nest a JSON body deeper than any client would. Expect 400 or 413 and a capped page, never a 50000-row response.
• Cost: for endpoints that send SMS or e-mail or call a partner, confirm that a per-user daily limit exists and is enforced by the server, not by the app.
• Place: only a test environment you are permitted to load, with numbers agreed with the team, because the test itself is load; never production and never anyone else's system.

Try it: API Response Analyzer Try it: API Schema Validator Try it: API Request Builder

Worked example: a security pass on a telecom self-service API

A telecom self-service API in the test environment, two customer accounts A and B with their own test lines, an OpenAPI document and written permission from the team. The plan covers five endpoints and the four risks above; expected results were written from the contract before the first request. Six of the eight checks found defects:

• C1, BOLA: B's token on GET /v1/accounts/A/invoices returned 200 with A's invoices instead of 404. Critical: any customer can read any customer's invoices.
• C3, broken authentication: a token from a session that had logged out was still accepted; logout only deleted it on the device. Major.
• C4, broken authentication: 50 wrong OTP codes in a row, all 400, no 429, no lockout. Critical: the login code can be guessed.
• C5, excessive data exposure: GET /v1/users/me returned nationalId and passwordHash, neither of which is in the contract. Critical: identity data and a password hash reach any client.
• C6, mass assignment: PATCH /v1/users/me with "planTier": "premium" returned 200, and a fresh GET showed the plan upgraded. Major, with a financial impact.
• C7, resource consumption: ?pageSize=50000 on the usage records of A's test line returned all 12000 records in one page, in nine seconds; the limit in the contract (100) was not enforced. Major.

Telecom self-service API, test environment. Customers A and B, each with a test line.

#   Risk  Request (actor)                               Expected     Observed
C1  API1  B: GET /v1/accounts/A/invoices                404          200, A's invoices
C2  API2  no token: GET /v1/users/me                    401          401
C3  API2  A after logout: GET /v1/users/me              401          200
C4  API2  POST /v1/auth/otp/verify, 50 wrong codes      429 early    50 x 400, no lockout
C5  API3  A: GET /v1/users/me, fields vs contract       contract     2 extra fields
C6  API3  A: PATCH /v1/users/me {"planTier":"premium"}  400/ignored  200, plan upgraded
C7  API4  A: GET /v1/accounts/A/usage?pageSize=50000    100 rows     12000 rows, 9 s
C8  API4  A: GET /v1/accounts/A/invoices, 60 in 10 s    429 after 30 429 from request 31

Try it: REST API Tester Try it: API Response Comparator

Frequently asked questions

References

• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.
• OWASP Cheat Sheet Series: REST SecurityOWASP FoundationSecurity rules for REST APIs: HTTPS, authentication on every request, input validation, safe error responses, rate limiting.
• RFC 6585: Additional HTTP Status CodesIETF · 2012Defines 428, 429 Too Many Requests, 431 and 511, including the Retry-After header for rate limiting.
• RFC 8725: JSON Web Token Best Current PracticesIETF · 2020The security rules for JWT implementations: reject alg=none, pin algorithms, validate iss/aud, use short lifetimes.