POCFORGE / API

API penetration testing

Human-led testing of REST and GraphQL APIs: object and function authorisation, token handling, data exposure and workflow abuse. Proof of what one caller can do to another, then a retest.

  • Human-led
  • Every reported finding reproduced
  • Retest included
Isometric illustration of an API gateway with request lines passing a shield checkpoint to stacked records, with the heading "API Penetration Testing", tagline "Authorisation, tokens, data exposure and workflow abuse", and the PoCForge logo.
  • Human testers leadTooling widens coverage only
  • Scoped firstScope and rules agreed before testing
  • Retest includedIn-scope fixes retested
  • Reproduced findingsEvidence a developer can replay

What we test

Broken object authorisation

Details

Can one user read or change another user’s objects by changing an identifier? Includes nested IDs, bulk endpoints and exports.

Broken function authorisation

Details

Do admin, partner or internal actions stay gated when called directly, including methods the client never shows?

Tokens and sessions

JWT and opaque tokens, API keys, refresh, expiry, audience and replay.

Details

JWT and opaque tokens, API keys, refresh, expiry, audience and replay. We do not treat a valid signature as proof the caller may act.

Excessive data exposure

Details

Fields the response returns beyond the caller’s need: secrets, other tenants, internal flags, or full objects where a view was intended.

Abuse and limits

Details

Whether limits exist on the routes that matter — login, OTP, money movement, invites — and whether they can be walked around with a trivial change.

GraphQL

Introspection, batching, aliasing and field-level access when GraphQL is actually in scope.

Details

Introspection, batching, aliasing and field-level access when GraphQL is actually in scope. We do not invent a GraphQL test for a REST-only product.

Workflow abuse

Ordering, refunds, tenancy and state a scanner will not chain.

Details

Ordering, refunds, tenancy and state a scanner will not chain. Multi-step proofs stay inside the rules of engagement.

Inventory

Details

Hosts, versions and forgotten routes that are in the test, including what mobile or partner clients call.

About this scope

APIs fail in the gaps between what the UI allows and what the server accepts. We test with real roles, not a single admin token, and we write down the object another tenant or user should never have seen.

Why API testing is not “the web test, minus the UI”

Example API attack pathExample API attack path (illustrative): caller A, then changes an object ID, then caller B's record, then bulk export. Example API attack pathSTEP 1Caller ASTEP 2Changes an objectIDSTEP 3Caller B’s recordSTEP 4Bulk exportIllustrative example. Real paths depend on what we find in scope.
Example API attack pathExample API attack path (illustrative): caller A, then changes an object ID, then caller B's record, then bulk export. Example API attack pathSTEP 1Caller ASTEP 2Changes an object IDSTEP 3Caller B’s recordSTEP 4Bulk exportIllustrative example. Real paths depend on what we find in scope.
Read more

The same authorisation bug is often invisible in the browser and obvious on the wire. BOLA-style access, mass assignment and function-level gaps show up when requests are rebuilt outside the client. A web-only pass that never leaves the happy path will miss them. Our notes on this class of bug are in API authorisation research, and a customer-safe example is the fintech API case study.

We still need the product context. A technically valid call that no role can reach is not the same finding as a call every customer can make. The report says which.

Fictional sample PoCForge "Application Security Assessment" report page with a blurred executive summary and a findings-by-severity chart, beside a High finding card for a missing authorisation check on a report export.

Deliverables

  • Executive summary that separates exploitable authorisation gaps from hygiene.
  • Technical findings with the request pattern, the role and the impact.
  • A short note of hosts and versions actually tested, so forgotten routes are visible.
  • Retest status for in-scope fixes.
More about the report

A report can support SOC 2 and ISO 27001 evidence. It does not certify the company, and it does not replace the auditor. PoCForge is not a certification body and does not claim CERT-In empanelment. If a contract names an empanelled auditor, read when CERT-In empanelment is required and check the official list before you shortlist.

Who this fits, and what stays out

A good fit

  • SaaS and fintech teams whose product is the API, or whose web or mobile client is a thin front on one.
  • It is the right engagement when a customer security review asks how you stop one tenant reading another.
  • Often scoped with web or mobile.

Worth knowing

  • It is the wrong engagement if you wanted a network scan of the VPC; that is cloud or external infrastructure.
  • A public API wider than one app should be named, not folded in by assumption.
More detail

Investment

Indicative global band $3,000 – $5,000 before taxes, for a focused API with a modest role set. Endpoint count, tenants, GraphQL and money-movement flows move the number. Confirm on the starting prices or the India API page.

TYPICAL INVESTMENT: $3K – $5K · taxes as applicable · final quote based on scope.

Scope and rules

  • Agree the API. Hosts, versions, auth schemes, roles, tenants and whether GraphQL, gRPC or partner APIs are included.
  • Accounts and docs. At least two roles that should not be equal. Specs help; undocumented routes are still in play if they are on the agreed hosts.
  • Map objects and functions. Which identifiers point at whose data, and which routes are supposed to be privileged.
  • Manual authorisation testing. Cross-user and cross-tenant attempts, token mistakes, and workflows. Tooling fills the inventory; it does not grade impact.
  • Report with requests. Reproduction a backend engineer can replay, including the role and the object that should have been denied.
  • Retest. Fixes that land in the window are checked again. New endpoints added later are not silently included.
Case study

Fintech API authorisation assessment

Anonymised fintech API authorisation assessment: how roles and money-adjacent endpoints were tested, the finding classes uncovered and how fixes were retested.

Read the case study →
How we work
  • Human-led
  • Every reported finding reproduced
  • Retest included

Related

Frequently asked questions

Do you test GraphQL as well as REST?

Yes, when GraphQL is in the agreed scope. Introspection, batching and field-level access are part of that pass. A REST-only product is not given a token GraphQL section.

Is this only an automated API scan?

No. Scanners miss cross-user authorisation and multi-step workflows. Those are tested manually and written up with evidence.

Do you claim CERT-In empanelment?

No. PoCForge does not claim CERT-In empanelment. Read the CERT-In guide if a contract requires an empanelled firm.

How does this differ from the web test?

The web test includes the UI and the calls it makes. This engagement is the API itself: roles, objects and functions, including clients other than your website.

Can one quote cover web and API?

Yes. Say so in the scope review. Combined India bands are published on the India API and web pages; global starting prices are on the pricing page.

Scope an API assessment

Send the hosts, the roles and whether GraphQL is in play. We will reply with a scope, not a generic package.

Request a free scope review →