API Security Testing Guide for Security Engineers

Before running any tests, map the API surface area completely. Automated scanning against an unmapped API will miss endpoints, methods, and parameters that are not linked from a starting URL.

API discovery techniques: (1) Obtain the API specification if available — OpenAPI/Swagger specs, Postman collections, and GraphQL introspection queries give you the complete endpoint and parameter map. (2) Intercept and proxy all application traffic with Burp Suite while manually walking through every application function — the proxy history reveals API calls that documentation may not reflect. (3) Review JavaScript source files for hardcoded API endpoints and client-side routing logic. (4) For GraphQL APIs, enable introspection (if not disabled in production) or use tools like Clairvoyance to enumerate the schema without introspection.

Set up a dedicated testing environment if at all possible. API tests that modify, delete, or enumerate data against production systems create real operational risk. If testing must be done against production, coordinate with the development team to understand data sensitivity and define a cleanup process for test artifacts.

Broken Object Level Authorization (BOLA, also called IDOR — Insecure Direct Object Reference) is the most prevalent and impactful API vulnerability class. An API endpoint that returns `/api/users/1234/profile` should verify that the authenticated user is authorized to access the data for user 1234 — not just that the user is authenticated. When authorization is missing at the object level, any authenticated user can access any other user's data by incrementing or guessing the ID.

Testing methodology: Authenticate as two different user accounts (User A and User B) in separate browser sessions. Capture a request made by User A that references a User A-owned resource ID. Replay that request using User B's session token. If the response returns User A's data, the endpoint is vulnerable to BOLA.

Extend this test to every endpoint that accepts an object identifier: numeric IDs, GUIDs, email addresses, usernames, filenames. Test not just GET requests but also PUT, PATCH, DELETE operations — broken authorization on write operations is often more severe than on reads. Use Burp Suite's Authorze extension to automate BOLA testing across a proxied session.

API authentication failures are the second most common vulnerability class and span a wide range: missing authentication on endpoints that should require it, weak JWT implementations, insecure token storage, and session fixation. Each requires a different testing approach.

JWT testing: Decode the JWT payload (base64, no decryption needed) and examine the algorithm field. Test for the 'none' algorithm attack by modifying the header to `{'alg': 'none'}` and removing the signature — if the server accepts it, the JWT library is dangerously misconfigured. Test for algorithm confusion attacks (RS256 to HS256 downgrade) using PortSwigger's JWT Editor Burp extension. Verify that JWTs are properly validated for expiration, issuer, and audience claims.

Key authentication tests: Identify endpoints that should require authentication (any endpoint that returns or modifies user data) and test them without a session token. Test whether removing the Authorization header, sending an expired token, or sending a token from a different user context produces an error or returns data. Many APIs correctly authenticate on some HTTP methods but not others — test GET, POST, PUT, DELETE, and PATCH separately for the same endpoint.

Mass assignment vulnerabilities occur when an API automatically binds client-supplied parameters to internal objects without filtering — allowing attackers to set properties they should not be able to modify, such as `isAdmin: true` or `accountBalance: 99999`.

Testing approach: Examine the API response for an object to understand its full property set (the response often reveals fields that should not be user-modifiable). Then submit a POST or PUT request that includes those additional fields and observe whether the server accepts and applies them. GraphQL APIs are particularly prone to mass assignment through mutation queries that accept input types without field-level access controls.

Excessive Data Exposure occurs when APIs return full objects and rely on the client to filter what is displayed, rather than filtering at the API layer. Look for API responses that return entire database records when only a subset of fields is displayed in the UI — the hidden fields in the raw API response (SSNs, password hashes, internal IDs, admin flags) represent actual data exposure even if the front-end does not render them.

Rate limiting gaps enable brute force, enumeration, and credential stuffing attacks against API endpoints that handle sensitive operations. Test by sending high-volume requests (hundreds per minute) to authentication endpoints, password reset endpoints, and OTP validation endpoints and observing whether rate limiting kicks in. Many APIs implement rate limiting inconsistently — it may be present on the web endpoint but missing on the mobile API endpoint for the same operation.

Security misconfiguration tests: check for verbose error messages that reveal stack traces, database queries, or internal hostnames; HTTP methods not in use that should be disabled (OPTIONS, TRACE); CORS misconfigurations that allow arbitrary origin access to authenticated endpoints; and HTTP security headers (X-Content-Type-Options, X-Frame-Options, HSTS) on API responses.

Business logic flaws are the class of vulnerabilities that automated scanners cannot detect because they require understanding the application's intended behavior. Examples: negative quantity values in order APIs that credit rather than debit accounts; race conditions in coupon code redemption that allow the same code to be used multiple times; sequential GUID patterns that allow future resource enumeration. These require manual testing with domain knowledge of the application's intended business rules.

API security testing requires a different methodology than web application testing — automated scanners cover less than 30% of the OWASP API Top 10 vulnerability classes. The highest-value manual tests are BOLA authorization checks (cross-account data access), JWT algorithm confusion, mass assignment via extra fields in PUT/POST requests, and business logic review. Burp Suite with the Authorze and JWT Editor extensions is the practical tool stack for most API security engagements.