API Security Testing: Protecting REST, GraphQL, and Webhook Endpoints

Why API Security Testing Is Different

APIs differ from traditional web applications in ways that affect how they are tested. Web applications have a user interface that guides the tester through flows: login, navigate, interact. APIs have no UI guidance, just endpoints that accept structured requests and return structured responses. The tester must construct requests manually or from documentation, which means the testing surface is harder to discover and easier to overlook.

APIs are also more exposed than web applications. A web application controls what actions the UI allows, and a user who wants to do something unusual must bypass the UI. An API client can send any request to any endpoint with any parameters in any order, because the client constructs requests programmatically without UI constraints. This means every authorization check, input validation rule, and business logic constraint must be enforced server-side because the client cannot be trusted to follow the expected flow.

The OWASP API Security Top 10 is the API-specific version of the OWASP Top 10, tailored to the risks most common in APIs: Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery, Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs.

Authentication Testing for APIs

API authentication typically uses tokens (JWTs, API keys, OAuth2 access tokens) rather than cookies. Each mechanism has specific test cases.

JWT testing. If the API uses JSON Web Tokens, test several attack scenarios. Check whether the API accepts tokens signed with the "none" algorithm, which would mean any token is valid without a signature. Check whether the API accepts tokens signed with a symmetric algorithm (HS256) when the server uses asymmetric signing (RS256), which is the algorithm confusion attack. Check whether the token expiration (exp claim) is actually enforced by submitting an expired token. Check whether the token can be tampered with by modifying claims (changing the user ID, changing the role) and submitting the modified token with the original signature. Tools like jwt.io decode tokens for inspection, and jwt_tool automates these attack scenarios.

API key testing. Check whether the API key is transmitted securely (in a header, not in a URL query parameter where it appears in server logs, browser history, and referrer headers). Check whether the API enforces key scope, meaning whether a key created with read-only permissions actually cannot write data. Check whether revoked keys are immediately rejected or whether they continue working due to caching.

OAuth2 testing. Verify that the authorization code flow checks the redirect_uri parameter strictly (not allowing open redirects that leak authorization codes). Verify that access tokens have appropriate scopes and that the API rejects requests that exceed the token's scope. Verify that refresh tokens are rotated on use (the old refresh token is invalidated when a new one is issued).

Missing authentication. Test every endpoint without any authentication credentials. Some APIs have endpoints that were intended to be authenticated but the middleware was not applied, especially common in microservice architectures where each service independently applies authentication. Use the API documentation (OpenAPI spec) to enumerate all endpoints and test each one without a token.

Authorization Testing for APIs

Authorization failures are the most common API vulnerability, ranking as BOLA (Broken Object Level Authorization) at the top of the OWASP API Security Top 10. The test is straightforward: can one user's API calls access another user's data?

Object-level authorization (BOLA/IDOR). Authenticate as User A and make requests that access User A's resources (GET /api/orders/123, GET /api/profile). Note the resource IDs. Authenticate as User B and repeat the same requests using User A's resource IDs. If User B receives User A's data, the API does not check whether the requesting user owns the requested resource. Test every endpoint that takes a resource identifier: numeric IDs, UUIDs, slugs, and email addresses are all targets.

Function-level authorization. Authenticate as a regular user and attempt to call admin-only endpoints. Common admin endpoints include user management (GET /api/admin/users, DELETE /api/users/{id}), configuration (PUT /api/settings), and data export (GET /api/export). Also test whether changing the HTTP method grants access: if GET /api/users/{id} returns the user for regular users, does DELETE /api/users/{id} also work?

Property-level authorization. Verify that API responses do not include properties the requesting user should not see. A regular user requesting their own profile should not receive admin flags, internal notes, or other users' email addresses in the response. Excessive data exposure happens when the API serializes entire database objects without filtering fields, which is especially common when using ORMs that automatically include all columns.

Mass assignment. Test whether the API accepts properties in write requests that the user should not be able to set. If the user update endpoint accepts a JSON body, try including properties like "role": "admin", "is_verified": true, "account_balance": 1000000. If the API blindly maps request properties to database fields without a whitelist, the attacker can modify any field by including it in the request.

Injection Testing for APIs

APIs accept structured data (JSON, XML, GraphQL) rather than the form-encoded data that traditional web scanners test. The same injection techniques apply, but the payloads travel in different containers.

SQL injection in JSON. SQL injection in API parameters works the same as in form fields: the payload is a string value in a JSON property that reaches a database query. Test every string property that could filter or identify database records: {"username": "admin' OR '1'='1"}, {"search": "test' UNION SELECT * FROM users--"}. Numeric fields can also be injectable: {"id": "5 OR 1=1"} if the API passes the value to a query without type checking.

NoSQL injection. APIs backed by MongoDB, CouchDB, or other NoSQL databases are vulnerable to NoSQL injection. Test with MongoDB operator payloads: {"username": {"$ne": ""}, "password": {"$ne": ""}} returns the first user if the API passes these objects directly to a MongoDB query. Test for JavaScript injection in MongoDB's $where clauses and aggregation pipelines.

GraphQL injection. GraphQL APIs accept queries as structured objects, but the query string itself can contain injection payloads. Test field arguments for SQL and NoSQL injection. Test for query depth attacks (deeply nested queries that consume server resources). Test for introspection to enumerate the entire schema: submit the introspection query {__schema{types{name,fields{name}}}} and check whether the API reveals its full schema structure. Production APIs should disable introspection.

Command injection. Test API endpoints that interact with the file system, execute system commands, or process file paths. Submit payloads that chain commands: {"filename": "report.pdf; whoami"}. Test for path traversal in file endpoints: {"path": "../../../../etc/passwd"}.

Rate Limiting and Resource Testing

APIs without rate limiting are vulnerable to brute-force attacks, credential stuffing, data harvesting, and denial of service. Test rate limiting on every security-sensitive endpoint.

Authentication rate limiting. Send 100 login requests in rapid succession with different passwords. Count how many the API processes before blocking. No rate limiting means the API allows unlimited password guessing. Weak rate limiting (blocking after 100 attempts but only for 1 minute) is barely better because automated tools can pace their attacks to stay under the limit.

Data endpoint rate limiting. Make rapid sequential requests to data endpoints (user lists, search results, product catalogs). Without rate limiting, an attacker can scrape the entire database through the API. Check whether rate limits apply per-user, per-IP, or per-API key, and whether changing any of these resets the counter.

Resource consumption. Test whether the API handles resource-intensive requests safely. Submit large JSON payloads (megabytes of data) and check whether the API rejects them or attempts to process them. Submit GraphQL queries with deep nesting or large result sets and check whether the API enforces query complexity limits. Submit file uploads at the maximum allowed size and check whether the API handles them without running out of memory.

Pagination bypass. If the API paginates results (limit and offset parameters), test whether the limit can be set to an unreasonably large value (limit=999999) to retrieve the entire dataset in one request. Test negative offsets, zero limits, and non-numeric values for robustness.

API Security Testing Tools

Postman is the most widely used API development tool, and its test scripting capabilities support security testing. Write pre-request scripts that manipulate tokens and authorization headers, and post-response tests that check for data exposure, proper error handling, and security headers. Postman Collections can encode security test suites that run against any API environment.

Burp Suite handles API testing through its proxy, repeater, and scanner. Import API requests by proxying through Burp or by importing Swagger/OpenAPI specifications. Burp's scanner tests API parameters for injection, authentication bypass, and other vulnerability classes. The Repeater tool lets you modify individual requests and observe responses, essential for manual authorization testing.

OWASP ZAP supports API testing through OpenAPI import, manual request proxying, and its active scanner. ZAP tests API parameters with the same injection payloads it uses for web forms, adapted for JSON and XML request bodies. Its API client allows scripted scanning from CI/CD pipelines.

GraphQL-specific tools. InQL (Burp Suite extension) provides introspection analysis, query generation, and automated testing for GraphQL APIs. graphql-cop performs automated security checks against GraphQL endpoints. Both tools understand GraphQL's query structure and generate test cases that generic API scanners miss.

For testing APIs that require valid data from external sources, ScraperAPI provides proxy rotation and anti-blocking capabilities that support large-scale API testing scenarios where you need to test rate limiting behavior from diverse IP addresses.

API Security in CI/CD

Automated API security testing in CI/CD follows the same pattern as web application testing but uses API-specific tools and configurations.

Schema validation. Validate every API response against the OpenAPI or GraphQL schema. Responses that include unexpected fields (potential data exposure) or accept unexpected request properties (potential mass assignment) should fail the pipeline. Tools like Spectral lint the API specification itself, catching security issues in the design before any code is written.

Contract testing. Security-focused contract tests verify that the API enforces authentication on every protected endpoint, returns only authorized data for each role, rejects injection payloads in all parameters, and enforces rate limits. These tests encode the API's security requirements as executable specifications.

DAST scanning. Run ZAP or Burp Enterprise against the API after deployment to staging. Import the OpenAPI specification to give the scanner full coverage of all endpoints. Configure authentication so the scanner can test protected endpoints. Set the pipeline to fail on critical findings.

The API testing discipline provides the foundation for API security testing, covering functional verification, performance, and reliability alongside security. Security testing adds the adversarial mindset: what happens when the API receives requests it was not designed to handle.

Common API Security Mistakes

Trusting the client. Any validation, rate limiting, or authorization logic that runs only on the client (frontend) is not a security control because attackers bypass the client entirely. Every constraint must be enforced by the API server.

Returning too much data. APIs that serialize entire database objects return internal fields (is_admin, password_hash, internal_notes) to every client. Use response schemas or serializers that explicitly whitelist which fields are included for each endpoint and role.

Predictable resource IDs. Sequential integer IDs (1, 2, 3) make it trivial to enumerate all resources. UUIDs make enumeration impractical but do not replace authorization checks, because a UUID can be leaked in URLs, logs, or other responses. Authorization must verify that the requesting user has permission to access the specific resource, regardless of how predictable the ID is.

Verbose error messages. Stack traces, database error messages, and internal path information in API error responses help attackers understand the application's internals. Production APIs should return generic error messages with error codes, while logging the detailed information server-side for debugging.