Your APIs carry most of the traffic your business depends on and most of the authorization decisions attackers care about. We test REST, GraphQL, and gRPC services endpoint by endpoint, object by object, and role by role, then hand your engineers findings they can reproduce and fix on the first pass.
Our test plans map to the OWASP API Security Top 10 and extend it with protocol-specific attack classes for REST, GraphQL, and gRPC. Each class below is exercised by hand against every in-scope endpoint and method, not sampled from a scanner queue.
BOLA, often reported as IDOR, remains the most damaging API flaw class in production systems. We substitute object identifiers across accounts and tenants on every endpoint that accepts one, including UUIDs assumed to be unguessable, references buried inside request bodies, and identifiers resolved through nested GraphQL fields.
We map every function the API exposes against every role permitted to reach it, then attempt each operation from the least privileged position: calling administrative routes as a standard user, switching HTTP methods on the same path, and invoking gRPC service methods the client was never intended to call.
Access control on an object is not access control on its fields. We test whether callers can read properties the API should filter out and write properties the server should own, such as verification flags, balances, quotas, and role attributes, across both REST resources and GraphQL types.
Frameworks that bind request bodies straight onto data models will accept fields you never advertised. We inject additional JSON properties and protobuf fields into create and update calls to determine whether values like is_admin, price, or owner_id can be set by the client, then demonstrate the impact on the affected records.
Many APIs return the full object and trust the client to filter it. We inspect every response for over-returned records, personal data, internal identifiers, and embedded secrets, and we check whether verbose errors, stack traces, and debug headers leak implementation details an attacker can build on.
SQL, NoSQL, command, and template injection delivered through JSON bodies, query parameters, GraphQL arguments, and gRPC metadata. Serialization layers change how a payload must be encoded, not whether the backend is vulnerable, so payloads are tailored to each protocol and content type in scope.
Shadow endpoints that never made the documentation and zombie versions that never got retired stay reachable long after your team stops thinking about them. We enumerate old API versions, debug and internal routes, and staging surfaces, then test what we find at the same depth as the documented API.
We measure what a single client can make your API spend: unbounded pagination, expensive query shapes, batch operations that multiply backend work, and missing rate limits on login, OTP, and enumeration-prone endpoints. Measurement is throttled and coordinated so it never becomes an outage.
Introspection left enabled in production, batching and aliasing used to smuggle brute force past per-request rate limits, deeply nested queries that saturate resolvers, and field suggestions that reveal hidden types. GraphQL deployments receive a dedicated test pass on top of the shared attack classes.
API engagements follow the same disciplined arc as every assessment we run, adapted to the realities of schema-driven systems and machine clients.
We collect what defines your API: OpenAPI documents, GraphQL SDL, protobuf definitions, Postman collections, and a walkthrough of the authorization model. You provision credentials for each role and tenant in scope, we agree on environments, test windows, and rate ceilings, and both sides sign the rules of engagement.
Testers work through the in-scope surface by hand, building an authorization matrix across roles, tenants, objects, and properties, and running each attack class against every endpoint it applies to. Anything that looks exploitable is confirmed with captured request and response evidence before it is written up.
The report arrives within five business days of testing completion: an executive summary for leadership and per-finding technical detail with reproduction steps, CVSS v3.1 ratings, and specific remediation at the code, gateway, or schema level. We then walk your team through it in a live debrief.
Once your fixes ship, we retest every reported finding once at no additional cost and reissue the report with verified statuses. You end the engagement with a closed document you can hand to customers, partners, or auditors, not an open list of maybes.
Test plans derive from the OWASP API Security Top 10 and the API sections of the OWASP Web Security Testing Guide, then extend past both, because published standards trail what working attackers do to schema-driven systems.
Scope is defined at the endpoint and method level, so both sides know exactly which surfaces are fair game before any traffic is sent. Where a specification exists we diff it against the running implementation, because the gap between what an API documents and what it actually serves is where findings concentrate.
Authentication receives the same scrutiny as authorization. Token issuance, validation, and revocation are tested as attack surfaces in their own right, including signature verification, algorithm confusion, audience and expiry handling, and the lifecycle of keys and client secrets.
An API assessment generates a large volume of raw traffic. What reaches you is the distilled result: findings that were confirmed with evidence, rated against your environment, and written so an engineer can reproduce and fix each one without a follow-up call.
Reports and evidence move only through an encrypted channel agreed at scoping, never by plain email, and remain available to you after the engagement closes.
Yes, and we encourage it. A specification lets us spend testing time on depth instead of discovery, and diffing the spec against the live implementation is itself a productive test. We do not stop at the document, though. Attackers are not limited to what you publish, so we also enumerate undocumented endpoints, retired versions, and debug routes, and we test whatever we find at full depth.
Yes. We build an authorization matrix covering every role and tenant combination against every endpoint, object, and writable property in scope, then attempt each cell of that matrix from the least privileged position. Most of the highest-severity findings we report on APIs come from this exercise. Automated scanners miss them because a scanner cannot know which caller is supposed to reach which object.
We agree on rate ceilings and test windows at scoping and throttle our tooling to respect them. Testing originates from dedicated source addresses we share in advance, so you can distinguish our traffic and allowlist it where needed. When rate limiting is itself the control under test, we ramp request volume gradually, record the threshold at which enforcement engages, and stop there rather than pushing into service degradation.
Yes. Service-to-service surfaces using client credentials grants, mTLS, and long-lived API keys are in scope, and they deserve attention because partner integrations often assume every caller is trusted. We test from the position of a compromised partner or a leaked credential, which is how these interfaces actually get attacked, and we examine whether one partner can reach another partner's data through your API.
A web application test assesses the browser-facing product, including the API calls it happens to make in normal use. An API engagement inverts that: the API is the target, so every method on every endpoint is tested directly, including operations no client currently calls, with the full authorization matrix and the protocol-specific classes above. Teams whose API serves browsers, mobile apps, and partners at once often pair the two assessments.
Send us your spec, or just the base URL. We will come back with a scope, a timeline, and a fixed quote within a few business days.