API Security Testing for REST and GraphQL

A technically valid API request is not necessarily secure. An authenticated user may still attempt to access another customer’s object, call an administrative function, retrieve unnecessary data or repeat a legitimate transaction in a way the business process did not intend.

OWASP’s API Security Top 10 identifies Broken Object Level Authorization, Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization and Unrestricted Access to Sensitive Business Flows among major API risks. Effective testing therefore verifies whether APIs behave securely for different users, roles, tenants, objects, methods, tokens and business states.

These areas reflect API risks and defensive practices described by OWASP and NIST.

REST testing examines endpoints, HTTP methods, parameters, authentication mechanisms and access-control decisions. Particular attention should be given to endpoints accepting user-controlled object identifiers. OWASP recommends object-level authorisation checks whenever an endpoint uses an identifier to access or act on an object.

Testing can also examine API keys, tokens, administrative endpoints, error responses and request limits. OWASP provides guidance for protected REST endpoints, rate limiting and API-key handling.

GraphQL allows clients to construct flexible queries and request related data in a single operation. Testing should review queries and mutations, field exposure, resolver behaviour, batching, error information and resource-intensive requests.

OWASP recommends limiting query depth and requested amounts because unrestricted GraphQL queries can consume excessive resources; pagination and related controls can also help manage this risk. Testing should also determine whether sensitive functions or properties remain reachable through GraphQL even when the user interface does not expose them.

Authentication establishes who or what is making a request; authorisation determines what that authenticated entity may do. OWASP emphasises that authentication does not automatically grant access to every resource or action.

Testing should cover role separation, tenant isolation, privileged operations and token handling. For JWTs and similar credentials, the assessment should consider validation, expiration and appropriate claim handling.

APIs should remain secure when valid functions are called repeatedly or with unexpected input. Rate and resource controls can reduce risks from automated requests, oversized payloads and computationally expensive operations. OWASP addresses unrestricted resource consumption in its API Security Top 10.

Server-side validation should be applied to untrusted input. File-processing endpoints require particular care because insecure uploads may introduce additional attack paths. OWASP recommends controls including allowlisted file extensions and defined file-size limits.

Business-logic testing looks for ways to skip required steps, repeat sensitive actions, bypass limits or execute workflows in an unintended order. OWASP includes unrestricted access to sensitive business flows as a specific API security risk.

Data-exposure testing checks whether an API returns information beyond what the caller needs or may access, such as internal fields, sensitive object properties or another account’s data. OWASP’s Broken Object Property Level Authorization category addresses inadequate property-level controls that can lead to unauthorised exposure or manipulation.

Maintain an accurate inventory of APIs and endpoints, including internal, partner-facing and legacy interfaces. Define user, service and tenant permissions clearly, and apply authorisation checks to every relevant operation instead of assuming that a valid token provides broad access.

Use strict server-side validation and appropriate limits for requests, files and resource-intensive operations. Protect API keys and tokens throughout their lifecycle, and avoid exposing sensitive credentials or unnecessary data in URLs, logs or responses.

For GraphQL, consider query-depth, amount, pagination and other resource controls appropriate to the application. For file endpoints, restrict file types and sizes and ensure users cannot unexpectedly control storage or processing behaviour. Retest important corrections after remediation, especially where changes affect authentication or permissions.

A practical engagement begins by defining the APIs, environments, authentication methods, representative accounts, roles and critical business flows. Testing then maps the relevant attack surface and exercises API functions using expected and adversarial request patterns.

Findings should be prioritised by technical severity, exploitation conditions and business relevance. Clear evidence and remediation guidance help teams understand what failed, why it matters and what should be corrected first.

ComplyMarket’s Cybersecurity Lab publicly lists API security testing covering authentication, authorisation, object access, rate limiting and data exposure, with an API vulnerability report as a typical output. It also lists remediation retesting after corrective actions.

Testing can be particularly useful before a major launch, after significant access-control changes, when introducing partner integrations, following architecture changes or after remediation of important vulnerabilities.

ComplyMarket provides cybersecurity testing and compliance support for products with digital elements. Its published Cybersecurity Lab scope includes API security testing and states that its methodology is risk based and adapted to the product type, regulatory scope and customer requirements.

ComplyMarket can also connect API findings with the wider product-security picture. Its Product Cybersecurity Assessment service reviews architecture, attack surfaces, trust boundaries, APIs, authentication, authorisation and other security controls, helping teams understand API weaknesses within the complete product ecosystem.

Depending on the agreed scope, findings can support prioritised remediation, stronger security evidence and verification of important fixes through retesting. This creates a practical path from identifying an API weakness to managing corrective action within broader product-security and compliance work.