---
title: API Security Testing
url: "https://cs.abinantony.io/services/api-security-testing"
updated: 2026-08-14
type: service
source: Abin Antony Security
---

# API security testing for REST, GraphQL and mobile backends

> API security testing is a manual assessment of REST, GraphQL or gRPC endpoints against the OWASP API Security Top 10. It targets broken object and function level authorisation, mass assignment, excessive data exposure, unrestricted resource consumption and authentication flaws that client-side testing cannot reach.

## Key points

- Every object reference is tested with a second account — broken object level authorisation remains the most common critical finding.
- GraphQL gets specific treatment: introspection, query depth and cost, batching abuse and field-level authorisation.
- Tested independently of any client, because that is how an attacker reaches it.
- Includes an OpenAPI/collection review so undocumented endpoints get found too.

Your API does not know that the mobile app hides the delete button. If authorisation is enforced in the interface rather than on the endpoint, the API is one curl command away from a data breach — and the request will look completely legitimate in your logs.

## What the engagement covers

### Authorisation testing on every object

BOLA and BFLA testing across all roles and tenants, using paired accounts so cross-account access is proven rather than assumed.

### Authentication and token security

JWT algorithm confusion and signature handling, token expiry and revocation, refresh-token rotation, API key scoping, and OAuth flow misuse.

### Data exposure

Endpoints returning more than the client renders, verbose errors, internal identifiers, PII in logs and analytics, and debug fields left in serialisers.

### Input handling and mass assignment

Injection across parameter types, mass assignment of privileged fields such as role or balance, and inconsistent validation between endpoints handling the same object.

### Resource consumption

Rate limiting, pagination limits, expensive query patterns, file upload sizes, and GraphQL query depth and complexity controls.

### Inventory and surface

Shadow and zombie endpoints, deprecated versions still routable, staging APIs reachable from the internet, and documentation that does not match reality.

## Method

01. **Specification review** — OpenAPI spec, Postman collection or captured traffic becomes the map; gaps between documented and live endpoints are flagged immediately.
02. **Role matrix** — A test matrix of every role against every endpoint and object — the artefact that makes authorisation testing complete rather than anecdotal.
03. **Manual exploitation** — Authorisation, authentication, injection and logic testing driven by hand, with tooling used for coverage rather than judgement.
04. **Chaining** — Findings combined into realistic attack paths — an ID leak plus a missing check is a full data export.
05. **Report and fix session** — Findings with raw requests and responses, plus a session with the backend team on the fix pattern.
06. **Free retest** — Verification of every fix and a reissued report within 30 days.

## Deliverables

- Endpoint-by-role authorisation matrix with pass/fail status
- Findings with raw HTTP requests, responses and reproduction commands
- Fix patterns for your framework, not generic advice
- OWASP API Security Top 10 coverage mapping
- Remediation walkthrough call
- Retest report and attestation letter

## Facts

| Field | Value |
| --- | --- |
| Duration | 1–2 weeks |
| Indicative price | from ₹60,000 |
| Standards | OWASP API Security Top 10, OWASP ASVS, CWE, CVSS 4.0 |
| Tooling | Burp Suite Pro, Postman, ffuf, GraphQL Voyager, Nuclei, jwt_tool, mitmproxy |
| Retest | Included free within 30 days |

## Questions

**We have no API documentation. Is that a problem?**

No. Endpoints are recovered from client traffic, the mobile bundle and directory enumeration. Undocumented endpoints are usually where the interesting findings live.

**Do you test GraphQL differently?**

Yes. Introspection exposure, query depth and cost limits, batching and aliasing abuse, and field-level authorisation are all specific to GraphQL and are tested separately from REST controls.

**Can this run alongside our mobile app test?**

It usually should. Bundling the app and its backend into one engagement removes the seam where each side assumes the other enforces authorisation.

**How do you avoid hammering our environment?**

Request rates are agreed up front, destructive verbs are opt-in, and testing pauses on request. You get a contact channel that is monitored for the whole window.


## Sources

- [OWASP API Security Top 10](https://owasp.org/API-Security/editions/2023/en/0x11-t10/)

---

Abin Antony Security — Abin Antony, Kochi, Kerala. Contact: abina35@gmail.com · https://cs.abinantony.io
