API Penetration Testing
CREST-accredited API penetration testing across REST, GraphQL, gRPC, and SOAP services, aligned with the OWASP API Security Top 10 and NIST guidance.
APIs are the operational substrate of the modern enterprise. They tie applications to backends, integrate SaaS, connect mobile to cloud, and increasingly carry the highest-value business logic in any organisation. They also concentrate risk in ways the surrounding UI layer rarely makes visible, which is why API-specific testing now consistently outproduces web testing for high-impact findings.
Vantage Point's API engagements combine threat modelling against the documented contract with deep manual exploitation against the running service. We test authentication, authorisation, data exposure, and business-logic flaws across REST, GraphQL, gRPC, and legacy SOAP services. Findings map to the OWASP API Security Top 10 and to the specific test cases in Velocity's API library.
Where APIs are mobile or browser-facing, engagements typically combine with the corresponding web or mobile testing service so authorisation can be tested end-to-end from the client through to the backend.
What's at stake.
APIs concentrate authorisation risk
A web UI gives one URL per page. An API gives hundreds of endpoints, each with their own authorisation contract. A single missing check on one of them is enough for a high-impact breach.
Documentation rarely matches reality
API specs drift from running services. Endpoints get added during emergencies, parameters acquire new meanings, undocumented paths persist for years. Testing against the running service finds what spec review cannot.
Mobile and partner integrations magnify exposure
APIs were often built for "the mobile app" or "this trusted partner". Once published, they get hit by everyone, including attackers reverse-engineering client code to find them.
What we test.
Authentication & authorisation
Where most API breaches actually start. Coverage maps to OWASP API Top 10 #1, #3, and #5.
- Broken object-level authorisation (BOLA / IDOR)
- Broken authentication
- Broken function-level authorisation
- JWT signature confusion and algorithm abuse
- OAuth flow weaknesses and consent abuse
Data, infrastructure & abuse
Categories that scale with API surface, and where consistent test cases catch what ad-hoc testing misses.
- Excessive data exposure
- Mass assignment
- Unrestricted resource consumption
- API injection (SQL, NoSQL, command, XML, JSON)
- Security misconfiguration and management endpoints
- Insufficient logging and monitoring
The flaws engagements like this consistently surface.
Drawn from common categories our consultants surface across engagements of this type. Severity and prevalence vary by environment and maturity.
BOLA / IDOR
Endpoints returning data scoped only by user-supplied identifier; numeric IDs incremented to enumerate other tenants; cross-tenant reads via internal reference fields.
Broken function-level authorisation
Admin endpoints reachable by any authenticated user; role checks present on UI but absent on the API; verb-based bypass (POST vs PUT) on protected paths.
JWT / token flaws
Tokens accepted with "none" algorithm, RS-to-HS confusion, missing audience claim validation, refresh tokens valid for far longer than session security warrants.
Excessive data exposure
Endpoints returning full user objects when only name and avatar are needed, internal IDs, computed flags, or backend system fields leaked to the client.
Mass assignment
POST/PUT bodies accepting fields the UI never sends, role, is_admin, balance, and silently updating sensitive attributes.
Rate limiting & abuse
Login endpoints without throttling, OTP endpoints reusable, expensive query endpoints with no quota allowing DoS via crafted requests.
A structured, intelligence-led path through every engagement.
Every engagement follows the same disciplined path through the Velocity platform, so quality, traceability, and reporting are consistent across teams.
Scoping
Define assets, environments, Rules of Engagement, and acceptance criteria with the technical and security stakeholders.
Execution
Manual and tool-assisted testing by CREST-accredited consultants, with evidence captured at each step.
Validation
Every finding is reproduced, risk-rated under CVSS, and confirmed by a second consultant before reporting.
Reporting
Cryptographically signed reports with test-case traceability, severity ratings, reproduction steps, and remediation guidance.
Debrief & Retest
Stakeholder walk-through of findings, prioritisation support, and a retest cycle on remediated issues.
Mapped to recognised baselines.
Common buyer questions.
Can you test if we only have OpenAPI / Swagger / GraphQL schema? +
Yes. Documentation is a starting point, we then enumerate the running service, including endpoints not in the spec, before manual testing. Most real-world findings come from this enumeration step.
How do you handle authenticated testing? +
You provide tokens or credentials for each role we should test under. We always test with at least two distinct roles to evaluate authorisation properly, typically standard user, administrator, and any tenant-scoped roles.
Do you test third-party APIs we depend on? +
Testing third-party APIs is typically prohibited by their terms of service. We focus on your own services, including the integration layer that consumes external APIs (where vulnerabilities are still your problem).
How does your testing differ for GraphQL vs REST? +
GraphQL has its own attack model: introspection, depth and complexity, batching abuse, broken object-level authorisation on type relationships. We test all of it with GraphQL-specific tooling and methodology.
Test Your Defences Against Adversarial Expertise
Talk to a CREST-accredited consultant about your next penetration testing engagement.