API Security Testing Checklist for QA Teams: Beyond Functional Testing

Your API test suite probably has hundreds of test cases. They verify that endpoints return the correct status codes, that request validation works, that pagination parameters are respected, and that error responses follow the documented format. These tests confirm that the API works correctly when used correctly.

API security testing asks a different question: what happens when someone uses the API incorrectly - on purpose?

The gap between functional API testing and security testing is not about tools or coverage metrics. It is about the mental model. Functional tests verify that the system does what it should. Security tests verify that the system does not do what it should not. These are fundamentally different exercises, and most QA teams only do the first.

This article provides a structured API security testing checklist organized by attack category. Each section explains what the vulnerability is, why functional testing misses it, and what specific test cases QA teams should add to their existing suites.

Category 1: Authentication Testing

Authentication is the first gate. If it fails, nothing else matters - every subsequent security control assumes the caller has been correctly identified.

Test Cases QA Teams Should Run

Token manipulation: Take a valid JWT, modify the payload (change the user ID, change the role claim, change the expiration), and send the modified token. Does the API reject it? Many implementations verify the token signature but fail to validate individual claims. A token signed with a valid key but containing a manipulated user ID should be rejected - but in practice, this is often not tested.

Algorithm confusion: If the API uses JWTs, send a token with the algorithm header changed to “none” or changed from RS256 to HS256. The “none” algorithm attack exploits implementations that accept unsigned tokens. The RS256-to-HS256 attack exploits implementations where the public key can be used as an HMAC secret. Both are well-documented attacks that still work against a surprising number of production APIs.

Expired and revoked tokens: Send requests with tokens that expired one second ago, one hour ago, and one year ago. Send tokens that should have been revoked (after a password change, after a logout, after account deactivation). Many APIs validate token format and signature but do not check expiration or revocation status - especially when token validation is cached for performance.

Missing authentication: For every authenticated endpoint, send the request with no authentication header at all. Then send it with an empty authentication header. Then send it with the string “null” or “undefined” as the token. Some API frameworks have default behaviors that pass unauthenticated requests through to handlers that assume authentication has already been verified.

Credential stuffing resistance: Send fifty login requests in rapid succession with different username and password combinations. Does the API rate-limit these attempts? Does it lock the account after repeated failures? Does it respond differently for valid usernames versus invalid usernames (allowing username enumeration)?

Why Functional Tests Miss This

Functional tests use valid tokens for authenticated requests. They never send malformed tokens, manipulated tokens, or no tokens at all - because the purpose of functional testing is to verify correct behavior, not to probe boundary conditions. The authentication layer is treated as infrastructure that works, not as a security boundary that must be actively verified.

Category 2: Authorization Testing

Authentication confirms who the caller is. Authorization controls what they can do. Authorization vulnerabilities are consistently among the most common and most impactful API security findings - and they are almost never caught by functional testing.

Broken Object-Level Authorization (BOLA)

BOLA (also known as Insecure Direct Object Reference or IDOR) is the single most common API vulnerability. It occurs when an API endpoint accepts a resource identifier (user ID, order ID, document ID) and returns the resource without verifying that the authenticated user has permission to access it.

Test case: Authenticate as User A. Request User B’s resources by changing the ID parameter. For every endpoint that accepts a resource identifier - /api/users/{id}, /api/orders/{id}, /api/documents/{id} - substitute an ID belonging to a different user and verify the request is rejected.

This is tedious. It needs to be done for every endpoint, for every HTTP method (GET, PUT, DELETE, PATCH), and for every resource type. Automation helps: maintain a test that authenticates as two different users, creates resources as each user, and then attempts cross-user access for every resource endpoint.

Broken Function-Level Authorization

Function-level authorization failures occur when users can access administrative or privileged API endpoints that should be restricted to their role.

Test case: Authenticate as a standard user. Attempt to call every admin endpoint: user management, configuration, reporting, data export, system health. These endpoints are often not listed in user-facing documentation but exist in the API and can be discovered through endpoint enumeration.

How to discover hidden endpoints: Review the API specification (OpenAPI/Swagger) if available. Check JavaScript source code in the web application for API calls. Use tools like Burp Suite or OWASP ZAP to proxy all traffic during a browser session and catalog every API endpoint the application calls. Many teams find endpoints they did not know existed.

Mass Assignment

Mass assignment occurs when an API endpoint accepts more parameters than it should and applies them to the underlying data model without filtering. A user update endpoint that accepts name and email might also accept role or is_admin if the API blindly maps request parameters to database fields.

Test case: For every endpoint that accepts a request body, add extra fields that correspond to privileged attributes: role, is_admin, permissions, account_type, plan, balance, credit. Send the request and verify that the extra fields were ignored, not applied.

Category 3: Injection Testing

Injection vulnerabilities in APIs follow the same principles as injection in web applications, but the attack surface is different. APIs accept structured data (JSON, XML, query parameters) rather than form inputs, and they interact with a wider range of backend systems.

SQL Injection in API Parameters

Test case: For every parameter that is used in database queries - filter parameters, search parameters, sort parameters, ID parameters - send SQL syntax: single quotes, OR 1=1, UNION SELECT statements, time-based blind injection payloads (' OR SLEEP(5)--). Monitor for error messages that reveal database details, for response time changes that indicate blind injection, and for unexpected data in responses.

Pay special attention to parameters that are not obviously database-bound. Sort parameters (?sort=name) are frequently interpolated directly into ORDER BY clauses without sanitization. Filter parameters (?status=active) may be concatenated into WHERE clauses. Pagination parameters (?page=1&limit=10) may be used in LIMIT/OFFSET clauses.

NoSQL Injection

If the API uses MongoDB, CouchDB, or another NoSQL database, SQL injection payloads will not work - but NoSQL injection payloads will. Send JSON objects where scalar values are expected: {"$gt": ""} for always-true conditions, {"$regex": ".*"} for data extraction, {"$where": "sleep(5000)"} for blind injection detection.

Test case: For login endpoints, send {"username": {"$gt": ""}, "password": {"$gt": ""}}. If this returns a valid session, the API has a critical NoSQL injection vulnerability that bypasses authentication entirely.

Server-Side Request Forgery (SSRF)

Any API parameter that accepts a URL - webhook URLs, callback URLs, image URLs, import URLs - is a potential SSRF vector. The API may fetch the provided URL from the server side, allowing an attacker to probe internal networks, access cloud metadata endpoints, or interact with internal services.

Test case: For every URL parameter, provide: http://169.254.169.254/latest/meta-data/ (AWS metadata), http://localhost:8080/admin (internal services), http://internal-service.local/ (internal DNS names). If the API fetches these URLs and returns the content (or behaves differently based on whether the URL was reachable), it has an SSRF vulnerability.

Category 4: Data Exposure Testing

APIs frequently return more data than the client needs. The frontend may display only three fields from a user profile, but the API response contains fifteen - including sensitive fields that the frontend ignores but an attacker reading the raw API response can see.

Excessive Data Exposure

Test case: For every API endpoint that returns user data, examine the full response body - not just the fields the UI displays. Look for: email addresses, phone numbers, internal IDs, creation timestamps, last login timestamps, IP addresses, password hashes, API keys, internal configuration, role information, or any field that was not explicitly requested.

Use a proxy tool (Burp Suite, mitmproxy, or browser developer tools) to capture raw API responses and compare them against what the UI displays. The difference is your data exposure surface.

Verbose Error Responses

Test case: Trigger errors deliberately - send malformed JSON, invalid parameter types, requests for nonexistent resources, requests that cause server errors. Read the error responses carefully. Do they reveal: stack traces, database table names, internal IP addresses, framework versions, file paths, SQL queries, or other implementation details?

Production APIs should return generic error messages with error codes. Any error response that reveals implementation details gives an attacker information they can use to craft more targeted attacks.

Response Header Leakage

Test case: Examine response headers for every endpoint. Look for: X-Powered-By (reveals framework), Server (reveals web server version), custom headers that reveal internal routing or infrastructure details, CORS headers that are overly permissive (Access-Control-Allow-Origin: * on authenticated endpoints).

Category 5: Rate Limiting and Resource Exhaustion

An API without rate limiting is an API that allows attackers unlimited attempts at everything - brute-force authentication, data scraping, denial of service, and enumeration attacks.

Rate Limit Testing

Test case: For every endpoint, send 100 requests in rapid succession. Does the API start rejecting requests? At what threshold? With what response code (429 is correct)? Does the rate limit apply per user, per IP, or globally?

Critical endpoints to test: Login endpoints (credential stuffing), password reset endpoints (enumeration), registration endpoints (spam), search endpoints (data scraping), data export endpoints (bulk data theft).

Pagination Exploitation

Test case: For endpoints that support pagination, request absurdly large page sizes: ?limit=999999. Does the API respect a maximum page size or does it attempt to return all records? An endpoint that returns unlimited records can be used for data exfiltration or can be exploited for denial of service by forcing the server to load massive result sets into memory.

GraphQL-Specific Testing

If the API uses GraphQL, test for: query depth attacks (deeply nested queries that cause exponential processing), batch query attacks (sending hundreds of queries in a single request), introspection exposure (the introspection query {__schema{types{name}}} should be disabled in production), and field suggestion exploitation (invalid field names that trigger suggestions revealing the schema).

Implementing the Checklist

Phase 1: Proxy Everything

Before writing test cases, run your entire QA suite through an intercepting proxy (Burp Suite, OWASP ZAP, or mitmproxy). This produces a complete catalog of every API endpoint your application calls, every parameter it sends, and every response it receives. This catalog is your testing scope.

Phase 2: Automate the Mechanical Checks

Authentication testing, header inspection, rate limit testing, and basic injection testing can be automated. Tools like OWASP ZAP (active scan), Nuclei (template-based scanning), and custom scripts using your existing test framework can run these checks in CI.

Phase 3: Add Manual Test Cases for Business Logic

Authorization testing and data exposure testing require understanding of the application’s business logic - which users should access which resources, which fields are sensitive, which operations should be restricted. These test cases must be written by people who understand the application.

Phase 4: Schedule Deep Testing for High-Risk Endpoints

Payment endpoints, authentication endpoints, admin endpoints, and any endpoint that handles sensitive data deserve focused penetration testing beyond what automated checks and QA test cases can provide.

The Checklist Summary

For every API endpoint in your application, verify:

• Rejects manipulated, expired, and missing authentication tokens
• Enforces authorization for every resource and every operation
• Sanitizes all input parameters against injection attacks
• Returns only the data fields the client is authorized to see
• Returns generic error messages without implementation details
• Enforces rate limits appropriate to the endpoint’s sensitivity
• Does not fetch attacker-controlled URLs from the server side
• Does not accept extra parameters that map to privileged attributes

Most QA teams will find that fewer than half of their endpoints pass all eight checks. That is not a failure of the QA team - it is a reflection of the fact that functional testing and security testing are different disciplines that require different test cases.

Talk to our API security specialists to scope an API Security Testing engagement. We test REST, GraphQL, and gRPC APIs against the full OWASP API Security Top 10 - and deliver findings with regression test cases your QA team can run in every sprint.