API Security Testing in 2026: The 10 Checks Every API Needs

Published April 7, 2026 · 11 min read

APIs are the primary attack surface for modern applications. Your mobile app talks to an API. Your single-page app talks to an API. Your microservices talk to each other through APIs. If your API security is weak, everything built on top of it is vulnerable.

These are the 10 checks that catch the most common API vulnerabilities. They're ordered by impact — the first few checks catch the bugs that lead to data breaches.

Check 1: Broken Object Level Authorization (BOLA)

What it is: The API lets you access other users' data by changing the resource ID in the request. Also known as IDOR (Insecure Direct Object Reference).

Why it's #1: BOLA is the most common API vulnerability and the most impactful. It leads directly to unauthorized data access — reading other users' profiles, orders, messages, or financial data.

How to test:

1. Authenticate as User A
2. Make a request to GET /api/users/123/profile (User A's profile)
3. Change the ID: GET /api/users/456/profile (User B's profile)
4. If you get User B's data, the API has BOLA

Test every endpoint that takes a resource ID: user IDs, order IDs, document IDs, message IDs. Test with sequential IDs, UUIDs (try guessing patterns), and IDs from other authenticated sessions.

Fix: Verify that the authenticated user has permission to access the requested resource on every request. Don't rely on the client to send the correct ID.

Check 2: Authentication Bypass

What it is: The API can be accessed without valid authentication, or the authentication mechanism can be bypassed.

How to test:

• Remove the Authorization header entirely — does the endpoint still respond with data?
• Send an expired token — does the API reject it?
• Send a token signed with a different algorithm (JWT algorithm confusion: change RS256 to HS256)
• Send a token with "alg": "none" — some JWT libraries accept unsigned tokens
• Test token refresh flow — can you reuse a refresh token after it should be invalidated?

Fix: Validate tokens on every request. Reject expired tokens. Use a well-tested JWT library with algorithm whitelisting. Implement token revocation for logout and password changes.

Check 3: Excessive Data Exposure

What it is: The API returns more data than the client needs. The frontend filters what to display, but the full response contains sensitive fields.

How to test:

1. Intercept API responses (Burp Suite, browser DevTools)
2. Compare what the UI shows vs what the API returns
3. Look for fields like: password_hash, ssn, internal_id, admin_notes, api_key
4. Check list endpoints — does GET /api/users return all user fields for every user?

Fix: Return only the fields the client needs. Use response schemas (DTOs) that explicitly define which fields are included. Never rely on the frontend to filter sensitive data.

Check 4: Rate Limiting

What it is: The API doesn't limit how many requests a client can make, enabling brute-force attacks, credential stuffing, and resource exhaustion.

How to test:

• Send 100 login requests in 10 seconds — does the API throttle you?
• Send 1000 requests to a search endpoint — does it slow down or return 429?
• Check if rate limiting is per-IP, per-user, or per-API-key (try rotating IPs)
• Test password reset endpoint — can you enumerate valid emails by brute-forcing?

Critical endpoints that MUST have rate limiting: login, password reset, OTP verification, signup, search, and any endpoint that triggers email/SMS.

Fix: Implement rate limiting at the API gateway level. Use sliding window counters. Return 429 Too Many Requests with a Retry-After header.

Check 5: Broken Function Level Authorization

What it is: A regular user can access admin-only API endpoints. The API checks authentication (who you are) but not authorization (what you're allowed to do).

How to test:

1. Authenticate as a regular user
2. Try accessing admin endpoints: GET /api/admin/users, POST /api/admin/settings, DELETE /api/users/456
3. Try changing HTTP methods: if GET /api/users/456 works, try PUT, PATCH, DELETE
4. Check for predictable admin paths: /api/v1/admin, /api/internal, /api/management

Fix: Implement role-based access control (RBAC) at the API layer. Check permissions on every endpoint, not just at the route level. Deny by default — only allow explicitly permitted actions.

Check 6: Mass Assignment

What it is: The API accepts and processes fields that the client shouldn't be able to set. A user can escalate privileges by including "role": "admin" in a profile update request.

How to test:

1. Find a PUT or PATCH endpoint (profile update, settings change)
2. Add extra fields to the request body: "role": "admin", "is_verified": true, "balance": 99999
3. Check if the extra fields were accepted and persisted
4. Try setting fields that appear in GET responses but aren't in the UI form

Fix: Use allowlists for accepted fields on every endpoint. Never bind request bodies directly to database models without filtering.

Check 7: Injection

What it is: API parameters are passed to backend queries (SQL, NoSQL, LDAP, OS commands) without proper sanitization.

How to test:

• SQL injection: test all parameters with ', 1 OR 1=1, UNION SELECT (see our SQLi detection guide)
• NoSQL injection: test with {"$gt": ""}, {"$ne": null} in JSON parameters
• GraphQL injection: test for query depth attacks, introspection, and batch query abuse
• Command injection: test parameters that might reach system commands (file paths, hostnames)

For XSS in API responses, see our XSS detection guide.

Fix: Use parameterized queries for all database operations. Validate and sanitize all input. Use an ORM correctly (don't build raw queries with string concatenation).

Check 8: CORS Misconfiguration

What it is: The API's Cross-Origin Resource Sharing configuration allows unauthorized domains to make authenticated requests.

How to test:

1. Send a request with Origin: https://evil.com
2. Check if the response includes Access-Control-Allow-Origin: https://evil.com
3. Check if Access-Control-Allow-Credentials: true is set with a permissive origin
4. Test with Origin: null — some APIs allow the null origin

The dangerous combination: Access-Control-Allow-Origin: * with Access-Control-Allow-Credentials: true. This lets any website make authenticated requests to your API using the victim's cookies.

Fix: Whitelist specific allowed origins. Never reflect the Origin header back without validation. Don't use * with credentials.

Check 9: API Versioning and Deprecation

What it is: Old API versions remain accessible and may have vulnerabilities that were fixed in newer versions.

How to test:

• If the current API is /api/v3/, try /api/v2/ and /api/v1/
• Check if old versions have weaker authentication or authorization
• Check if old versions expose endpoints that were removed in newer versions
• Test if old versions have the same rate limiting as current versions

Fix: Deprecate and remove old API versions on a defined schedule. If old versions must remain, apply the same security controls as the current version.

Check 10: Error Handling and Information Disclosure

What it is: API error responses leak internal information — stack traces, database queries, file paths, server versions.

How to test:

• Send malformed requests (invalid JSON, wrong content type, missing required fields)
• Send requests that trigger server errors (very long strings, special characters, null bytes)
• Check if error responses include: stack traces, SQL queries, file paths, internal IP addresses, framework versions
• Test 404 responses — do they reveal the web framework?

Fix: Return generic error messages to clients. Log detailed errors server-side only. Use a consistent error response format that never includes internal details.

Putting It Together

These 10 checks cover the most common and impactful API vulnerabilities. Run them in order — BOLA and authentication bypass are the highest-impact findings, so test those first.

For a broader web application testing workflow, see our complete security testing checklist. For automated API security scanning, SecurityClaw's api-schema-discovery, idor-scanner, and apigw-cors-tester skills cover checks 1, 5, and 8 — see our OWASP coverage analysis for the full mapping.