API Security Assessment

APIs concentrate risk because they expose business logic directly, often to partners whose own security posture is unknown. Object-level and function-level authorisation flaws dominate what we find: an endpoint that checks whether you are authenticated but not whether the record belongs to you. We test against the OWASP API Security Top 10, working through broken object level authorisation, broken authentication, property-level exposure, resource consumption limits, function-level authorisation, sensitive business flow abuse, server-side request forgery, and inventory management. GraphQL scope adds introspection exposure, query depth and complexity limits, and batching abuse. Partner and machine-to-machine integrations are assessed for credential handling, token scope and replay resistance.

What the engagement covers

An API security assessment tests the interface that carries your business logic, usually to consumers whose own security posture you do not control. Scope covers REST and GraphQL endpoints, authentication and token issuance, partner and machine-to-machine integrations, and the documentation or schema that is supposed to describe them. Testing follows the OWASP API Security Top 10 as the structural reference, extended with the OWASP Testing Guide v4.2 for issues that are not API-specific.

The first task is establishing what actually exists. Published documentation is compared against observed routes, historic client bundles, mobile application traffic and schema introspection. Undocumented, deprecated and staging endpoints reachable from production are a recurring source of high-severity findings, because they are outside whatever review process governs the documented surface.

Authorisation before everything else

Broken object level authorisation remains the most productive class of finding in API testing. The pattern is consistent: an endpoint verifies that the caller is authenticated, then acts on whatever identifier the caller supplied. We test every endpoint that accepts an identifier with credentials from a second account, including identifiers that are opaque or non-sequential — obscurity delays enumeration, it does not prevent access.

Function level authorisation is tested by exercising administrative and privileged routes with ordinary user credentials, including HTTP method variations that some frameworks route differently from the documented verb. Property level authorisation is tested in both directions: whether responses expose fields the caller should not read, and whether requests accept fields the caller should not write. Mass assignment through a permissive object binder is still one of the fastest routes to privilege escalation we encounter.

Tokens, sessions and integrations

Token handling is reviewed for issuance, scope, lifetime, revocation and validation. Common findings include tokens that carry authorisation claims the resource server does not re-verify, refresh tokens without rotation or reuse detection, scopes that are requested correctly but never enforced, and JWT validation that accepts an unexpected algorithm or skips audience checks. Where the platform issues credentials to partners, we review how those credentials are provisioned, rotated and revoked, and what a partner compromise would reach.

GraphQL-specific scope

Where GraphQL is in scope, the assessment adds introspection exposure, query depth and complexity limits, alias-based and batched request amplification, and authorisation enforcement at the resolver rather than the query level. A schema that enforces access control on the top-level query while resolvers fetch related entities without a check is a pattern we test for specifically, because it is easy to introduce and hard to see in review.

Resource consumption and business flows

Rate limiting is tested for existence, placement and evasion: whether limits are enforced per credential and per resource rather than only per IP address, whether they survive distribution across addresses, and whether expensive operations — report generation, export, search with wide filters — carry tighter limits than cheap ones.

Sensitive business flow testing asks what an automated caller could achieve at scale that a single user could not: reserving inventory, enumerating account existence through timing or error differences, harvesting personal data through a legitimate lookup endpoint, or driving cost through a paid downstream service. These findings rarely appear in scanner output and are usually the ones that matter commercially.

Output

Findings are mapped to the OWASP API Security Top 10 category and scored with CVSS 4.0. The report includes the verified endpoint inventory, with undocumented and deprecated routes flagged, so the client finishes the engagement with an accurate picture of their own attack surface. Remediation guidance includes example fixes in the client's framework where that is more useful than a generic recommendation. A retest confirms closure.