Skip to main content
Threatsys

Cyber Security Testing

API Security Testing

Authentication, authorisation, rate-limiting and business-logic testing across REST, GraphQL and gRPC.

API Testing as-a-Service

Every engagement includes manual validation, a two audience report and free re-testing.

Get a scoped quote+91 96682 00222

What this actually is

APIs have quietly become the largest attack surface most companies own, and the least tested. They were built for internal use, then opened to a partner, then to a mobile app, and the authorisation model never quite caught up.

The flaws we find are rarely exotic. An endpoint that checks you are logged in but not whether the record belongs to you. A parameter that was never meant to be user-controlled. A rate limit on the login page but not on the OTP check behind it.

We test REST, GraphQL and gRPC, and we test them with the client removed, because that is the only honest way to know whether the server is enforcing anything at all.

What we go after

  • Broken object level authorisation across every endpoint
  • Function level authorisation and role escalation
  • Mass assignment and unexpected parameter injection
  • Authentication, token handling and JWT implementation
  • Rate limiting, enumeration and resource exhaustion
  • GraphQL introspection, batching and query depth abuse
  • Business logic sequencing and race conditions
  • Data exposure in responses and error messages

How we run it

  1. 01

    Scope and authorise

    Targets, testing windows, escalation contacts and safety limits, all agreed in writing before anyone touches anything.

  2. 02

    Map the surface

    We enumerate what is actually exposed, which is usually more than the asset register says.

  3. 03

    Test by hand

    Tooling gives coverage, our engineers give proof. Every finding is reproduced before it is written down.

  4. 04

    Report

    An executive narrative your board can act on, and a technical annexe with the exact request, payload and fix.

  5. 05

    Re-test and sign off

    Once you have fixed it we verify each one at no extra cost, then close the engagement properly.

What you receive

  • Endpoint-level findings with the exact request that proves each one
  • Authorisation matrix showing what each role can actually reach
  • A collection of the proof cases you can re-run yourself
  • Prioritised remediation plan
  • Free re-test after fixes

Who needs this

Anyone exposing APIs to a mobile app, a partner, or the public internet. If your API predates your current authorisation model, this is overdue.

How long it takes

One to two weeks depending on endpoint count.

Standards this satisfies

  • OWASP API Security Top 10
  • CERT-In
  • PCI DSS
  • ISO 27001

Why it matters

Your API is larger than your interface and is usually tested less. Every mobile app, partner integration and single page front end talks to it directly, which makes the authorisation logic in the API the real control rather than anything enforced in the interface.

The failures we find are almost never authentication. The caller is legitimately logged in. They are simply able to read or change a record belonging to someone else, because the check was written against the session and not against the object.

Choose the depth you actually need

Most of the price difference between quotes comes down to this one choice, and it is rarely explained. Pick one to see what it covers, what it suits and what it costs you.

You give us working accounts at each privilege level and a short walkthrough. We then test what a real attacker reaches after the first stolen password, which is where the findings that matter almost always live. This is what we recommend for most engagements.

Choose this when

  • Any application with authenticated functionality
  • Multi-tenant products, where tenant isolation is the real risk
  • Getting the most findings for the money

Effort and cost

Moderate effort and by far the best coverage per rupee. Most of the serious findings we report come out of authenticated testing rather than unauthenticated.

Tested against OWASP ASVS, not a checklist we invented

We test to the OWASP Application Security Verification Standard, which sets verification levels across authentication, session management, access control, input validation, cryptography, error handling and business logic. Working to a published standard means you can tell an auditor or a customer exactly what was verified and to what depth. It also makes this year's test comparable with last year's, which a bespoke in-house checklist never is.

Scope it yourself, before you call anyone

Answer a few questions and you get an indicative number, the working behind it and what your answers tell us. It runs in your browser, so nothing you type reaches us.

1/5

What needs testing?

Pick everything in scope. Effort is driven by unique functionality, not by how many IP addresses you own.

What we look for, and keep finding

These are the classes of problem this work exists to surface. Not every engagement finds all of them, but these are the ones that turn up often enough to be worth naming.

  • Broken access control

    The most common serious finding we report, and the one scanners miss most reliably. An identifier that is not checked against the caller, an admin function reachable by guessing its path, a role that can be changed in the request. The user is logged in. They are simply reading or doing something that is not theirs.

  • Injection and unsafe query construction

    SQL, NoSQL, OS command and template injection. Modern frameworks prevent most of it, which is exactly why the remaining cases hide in the hand written query somebody added under deadline, or in the reporting module nobody has looked at since it shipped.

  • Authentication and session weaknesses

    Tokens that do not expire, password reset flows that can be redirected, multi-factor that can be skipped by replaying an earlier step, and sessions that survive a password change. We test the whole lifecycle rather than just the login form.

  • Business logic abuse

    Nothing is technically broken. The application simply allows a sequence it should not: a discount applied twice, a payment confirmed before it clears, a limit avoided by splitting a request. This requires understanding what the application is for, which is why automation cannot find it.

  • Sensitive data exposure

    Data returned by an API that the interface never displays, secrets in client side code, verbose errors that reveal structure, and personal data in logs. The response body is where we find most of it.

  • Security misconfiguration

    Default credentials, directory listing, debug endpoints reachable in production, permissive CORS and missing security headers. Individually minor, and routinely the first step in a chain that ends somewhere serious.

Who runs your engagement

A senior tester, named before you sign

Testing is led by an engineer holding OSCP, CREST or equivalent, and you are told who it is before the engagement starts. They write the report themselves rather than handing notes to someone else, and they are on the call when findings are walked through. If the person changes, we tell you why.

Questions we get asked

We have API documentation. Is that enough for you to test?

It is a good start and it speeds us up. We also enumerate beyond the documentation, because undocumented endpoints are consistently where the worst findings live.

Can you test without disrupting our partners?

Yes. We use dedicated test accounts, agree rate limits with you up front, and only perform destructive operations against records we created ourselves.

Often scoped alongside

Ready to scope your api security testing?

Thirty minutes with a senior engineer, and you leave with a written scope and indicative effort.

Book a 30-min consultation+91 96682 00222