API penetration testing for REST and GraphQL

API penetration testing is a manual attack on the interfaces your apps, partners and integrations call directly. Most serious API breaches come from broken authorisation: an API that returns another customer's object because the ID changed. ITovio tests every endpoint and role for that, plus mass assignment, SSRF and business-flow abuse, and proves each finding.

Enterprise only. Cyber security is the one service ITovio offers at enterprise level: established companies and enterprises with production systems worth attacking properly. We do not sell low-budget scans or small-business security packages.

Who this is for
  • Platforms whose mobile app, single-page front end or partners talk to a public API.
  • Companies exposing GraphQL, webhooks or partner integrations.
  • Enterprises with internal APIs that became reachable through a gateway, a migration or a forgotten version.
  • Teams preparing for an enterprise customer's security review of their API.
What we promise

Definitive results, not maybes

Proven, not suspected

Every finding in the report is exploited by hand and shipped with a working proof of concept, reproduction steps and evidence. No unverified scanner output, no "potential" issues padding the page count.

Ranked by business impact

Severity is scored with CVSS and then argued in plain language: what an attacker reaches, which data, which customers, what it would cost you.

Closed means closed

After you fix, we attack the same issue again. The retest report states, per finding, whether it is closed, partly closed or still open.

A clean result is still a result

If a target holds, the report says exactly what was attacked, how and for how long, so "nothing exploitable found" is evidence you can hand to a customer, auditor or board.

What we test, mapped to the OWASP API Security Top 10

RiskHow we attack it
Broken object level authorisationEvery object ID, in every endpoint, swapped between users and tenants; UUIDs harvested from other responses rather than guessed
Broken authenticationToken issuance and validation, JWT algorithm and key confusion, refresh token reuse, API keys in clients, OAuth flows
Broken object property level authorisationMass assignment of fields such as role, price or owner; excessive data returned and filtered only in the client
Unrestricted resource consumptionMissing limits on pagination, batch size, file size and expensive operations, tested safely without taking you down
Broken function level authorisationAdmin and internal functions callable by ordinary users, HTTP method switching, version downgrades
Access to sensitive business flowsAutomated abuse of sign-up, checkout, booking, voucher and referral flows
Server-side request forgeryURL and webhook parameters pointed at internal services and cloud metadata endpoints
Security misconfigurationCORS, verbose errors, debug and documentation endpoints left open, inconsistent behaviour across gateways
Improper inventory managementOld API versions, shadow endpoints and staging hosts still reachable and still trusted
Unsafe consumption of APIsTrust placed in third-party API responses that an attacker can influence

GraphQL gets its own pass

  • Introspection and schema reconstruction even when introspection is disabled.
  • Authorisation on every resolver and nested field, not just the top-level query.
  • Batching and alias abuse to bypass rate limits and brute-force protections.
  • Query depth and complexity limits, tested without degrading service.
Questions

Asked before most engagements

What do you need to test an API?
An OpenAPI or GraphQL schema if you have one, a Postman collection or traffic from your client apps, and test accounts for each role in two tenants. Without documentation we reconstruct the API from the clients, which takes longer.
Is API testing included in a web application test?
The API behind a web application is tested as part of it. Public, partner or mobile APIs with their own consumers are usually scoped separately so every endpoint gets attention.
How do you avoid damaging data?
Write operations are tested on test accounts and test tenants we create or you provide. Anything destructive is agreed first or run against staging.
Do you test rate limits?
Yes, by showing whether a limit exists and whether it can be bypassed, not by flooding production. Denial-of-service testing is excluded.

Reviewed by the ITovio security team on 3 November 2026.

Find out what an attacker would find first.

A 30-minute scoping call, then a written scope with targets, depth, windows and deliverables before you commit. Enterprise engagements only.

Book a call WhatsApp
WhatsApp