Cybersecurity Services
API Security
Discovery and exploitation testing for every REST, GraphQL, gRPC and webhook endpoint you run, including the undocumented ones, the deprecated versions and the internal services nobody meant to expose.

- OWASP API Top 10
- Covered And Exploited, Not Just Checked
- Shadow + zombie
- Undocumented And Deprecated APIs Found
- Per endpoint
- Object And Function Authorisation Tests
- Protocols
- REST, GraphQL, gRPC, SOAP
- Discovery
- Spec, Traffic, Bundles, Enumeration
- Auth Models
- OAuth2, JWT, API Key, mTLS
- Top Risk
- BOLA / Object Authorisation
- Output
- SARIF, JSON, Postman Replay
Problem
- The Issue
- Impact
The real endpoint surface, not just what the spec documents
Object and function authorisation cross-tested per identity
Schema-aware fuzzing that reaches the handler, not the validator
The API is the application, and it is tested least
Your web and mobile clients are convenience layers over an API that enforces (or fails to enforce) every authorisation rule you have.
AIPTx tests that API directly: every endpoint, every version, every object identifier, with no help from the UI that normally hides the dangerous ones.
Why Test APIs
- Key Benefits
The problem: APIs fail differently from web pages
The problems below appear in almost every assessment, regardless of stack or industry, and each is invisible to a client-driven test.
Changing one number returns another customer's invoice, the single most exploited API flaw, and one that is indistinguishable from legitimate traffic in every log.
- Endpoints nobody documentedVersion prefixes left running after a migration, deprecated releases still answering requests, and internal services that a gateway or ingress rule quietly made reachable from outside. None of them appear in the specification, so none of them are tested.
- Object authorisation fails silentlySwapping one identifier for another returns a record belonging to a different account, and the request is well-formed, authenticated and indistinguishable from legitimate use. Nothing in the logs marks it as an attack, so it survives until someone tries it deliberately.
- Enforcement lives in the clientThe web bundle or mobile app hides the privileged action, but the handler behind it never re-checks the caller's role. Any request made outside that interface (with curl, a proxy or a script) reaches the function unchallenged.
- Data leaks in both directionsResponses return the whole object and leave the client to display a subset, exposing fields the caller was never meant to read. Inward, an unfiltered request body lets a caller set attributes such as role, ownership or balance that the endpoint never intended to accept.
- GraphQL and gRPC undercountedOne /graphql path or one gRPC service is recorded as a single tested endpoint, when every resolver and every method is its own authorisation decision. Coverage reads as complete while most of the surface behind it has never been exercised.
- Machine-to-machine paths untestedLong-lived service tokens with no revocation, webhook callbacks accepted without signature verification, and rate limits applied per IP rather than per identity. These paths have no interface to drive them, so a client-driven test never reaches them.
Key Benefits
Why API-first testing is a must for every business
An Inventory That Matches Reality
Discovery routinely finds versions absent from the spec, the ones without the current fixes.
Authorisation Tested Where It Fails
BOLA proven by one account reading another's record, not inferred from a code review.
Fuzzing That Reaches The Handler
Typed input built from your own schema passes validation and tests the logic behind it.
Evidence A Developer Can Run
Every finding ships as a replayable request, which removes the reproduction step entirely.
Contract Changes Tested On Merge
A spec change triggers targeted testing of the endpoints it touches, before production.
Machine-To-Machine In Scope
Tokens, webhook signatures and mTLS assumptions tested with no interface to drive them.
How It Works
- Approach
- Workflow
How AIPTx tests an API
Discovery first, because the endpoints you already know about are rarely where the problem is. Then authenticated exploitation, endpoint by endpoint and identity by identity.
- 01
Build The Real Inventory
Specs, introspection, client bundles, proxied traffic and enumeration combined into one surface.
- 02
Model Schema & Identities
Types, required fields and relationships, plus which object belongs to which account.
- 03
Attack Authentication
Algorithm confusion, expiry and revocation, scope enforcement, refresh flows and mTLS.
- 04
Cross-Test Authorisation
Every identity against every other identity's objects, and every privileged function.
- 05
Fuzz & Abuse Flows
Typed fuzzing, mass-assignment probes, quota and rate-limit abuse, webhook forgery and SSRF.
| API Surface | What We Assess |
|---|---|
| REST & JSON-RPC | BOLA, BFLA, Mass Assignment, Over-Fetching, Injection |
| GraphQL | Per-Resolver Authorisation, Depth, Batching, Introspection |
| gRPC & Protobuf | Reflection, Per-Method Authorisation, Typed Fuzzing |
| Authentication | JWT Attacks, Scope Escalation, Key Leakage, mTLS Enforcement |
| Rate & Quota | Per-Identity Limits, Pagination Abuse, Cost Amplification |
| Webhooks | Signature Forgery, Replay Windows, SSRF Via Callbacks |
What We Cover
- Scope
What gets tested
Coverage follows the OWASP API Security Top 10, with the object-authorisation classes given the weight their exploitation rate deserves.
Shadow & Zombie Discovery
Version enumeration, bundle path extraction, certificate transparency and internal exposure checks.
Object Level Authorisation
Identifiers swapped, enumerated and replayed across read, update, delete and export operations.
Function Level Authorisation
Admin route probing, HTTP method override and role escalation from low-privilege tokens.
Token & Key Security
JWT algorithm confusion, weak secrets, missing revocation, scope escalation and key leakage.
GraphQL-Specific Testing
Resolver authorisation, query depth and complexity abuse, alias and batch brute force.
Consumption & Integrations
Per-identity rate limits, pagination and cost abuse, webhook forgery and third-party data handling.
Proven Impact
- Outcomes
What API-first testing gives you
Testing the API directly finds the flaws that a client-driven assessment structurally cannot reach.
- Complete
- An inventory that matches reality
- Per object
- Authorisation tested where it fails
- Schema-aware
- Fuzzing that reaches the handler
- Replayable
- Evidence a developer can run
- Pipeline-ready
- Contract changes tested on merge
- M2M covered
- Service-to-service paths in scope
Where It Fits
- Use Cases
Where API testing changes the outcome
Across industries. Across environments. For every modern business.
API-First Products
Close authorisation and quota gaps before external developers find them.
Mobile Backends
Attack the API without the client's restrictions: arbitrary identifiers, tampered payloads.
Microservices Estates
Find internal services that ingress or gateway misconfiguration made external.
Fintech & Payments
Test money-moving endpoints, webhook trust and idempotency under replay.
Financial Services
Prove per-object access rules across partner and open-banking interfaces.
Government & Public Sector
Evidence endpoint inventory and authorisation coverage for assurance reviews.
FAQ
API security questions
How do you find APIs we have not documented?
Several ways at once: parsing client bundles and mobile binaries for paths, enumerating version prefixes and route patterns around known endpoints, reading gateway and ingress configuration, mining certificate transparency and DNS data, and optionally proxying live traffic. Undocumented endpoints are flagged separately, because an endpoint nobody knows about is usually an endpoint nobody patched.
What do you need to start, a spec or credentials?
Credentials matter more. An OpenAPI document, Postman collection or GraphQL schema speeds discovery and improves fuzzing accuracy, but the important work needs at least two distinct identities (ideally in different tenants) so object and function level authorisation can be tested by cross-access rather than inferred.
Do you support GraphQL and gRPC properly?
Yes. GraphQL is tested per resolver rather than per endpoint, covering introspection exposure, nested-query depth, alias and batch abuse and field-level leakage. gRPC services are tested from reflection or supplied protobuf definitions, with the same authorisation cross-testing applied to each method.
How is BOLA testing actually performed?
The agent collects object identifiers while operating as each identity, then systematically attempts to access each identity's objects using the others' tokens, across read, update, delete and export operations. Every success is captured as a replayable request with the returned data redacted in the report.
Can this run against production safely?
Requests are rate limited to a threshold you set, destructive methods can be excluded per endpoint, and the agent prefers proving access by reading a single record over modifying anything. Many teams run full-depth testing against staging and non-intrusive authorisation checks against production.
Do you test rate limiting and resource consumption?
Yes, and carefully, because the honest version of this test looks like the attack it is checking for. The agent measures where throttling actually engages per identity and per endpoint, and probes unbounded pagination, oversized payloads, expensive GraphQL queries and unrestricted export operations, all inside the request-rate ceiling you set. It establishes that a limit exists and where it sits rather than trying to exhaust anything.
Find the endpoints your documentation forgot
Point AIPTx at your API with two sets of credentials and it will map the real endpoint surface, cross-test every object and function, and show you exactly which caller can reach what.
Explore other services
Web Application Security
Deep authenticated testing for the apps you ship.
AI Penetration Testing
Simulate real-world attacks to test your defences.
Vulnerability Assessment
Find, rank and fix weaknesses across the whole estate.
Vulnerability Discovery
The seven vulnerability classes and how each finding is validated and classified.