API Penetration Testing
Quoted on scope, fixed price. Includes the Vexil platform and a hand-verified retest.
Teams who have had us test their systems
- Selip & Stylianou, LLP
What this covers
Your API is the backbone of your product - every frontend, mobile app, and integration partner depends on it. It is also the attack surface that gets tested last. While your web app gets tested, your API endpoints often ship with object-level authorization gaps that expose every user's data. We test REST, GraphQL, and gRPC APIs against the OWASP API Security Top 10. Our testing goes far beyond automated scanning: we manually test every endpoint for broken object-level authorization (BOLA/IDOR), broken function-level authorization, mass assignment, and rate-limit abuse. We chain findings into real attack narratives - "an attacker can enumerate user IDs and access any account's private data" - not just "IDOR on /users/{id}." Every finding includes the exact request/response pair, a severity rating, and a framework-specific fix recommendation. A re-test is included in the engagement, after your devs patch.
- Ship public APIs with confidence that every endpoint is authorization-gated
- Close enterprise deals faster with a professional API security audit report
- Catch the #1 API vulnerability (broken object-level auth) before a breach does
- Get rate-limit and abuse-resistant endpoints your platform team can trust
Scope
What gets tested
Ten areas, agreed on the scoping call and written into the rules of engagement before anything starts.
REST API Security
Endpoint enumeration, method-based auth bypass, content-type abuse, CORS misconfigurations, parameter pollution.
GraphQL Security
Introspection abuse, query depth/alias/cost attacks, field-level auth gaps, batching brute force, subscription exhaustion.
gRPC Security
Service reflection enumeration, protocol buffer fuzzing, metadata-based auth bypass, streaming connection abuse.
Authentication & Tokens
JWT algorithm confusion, weak signing keys, OAuth2/OIDC misconfigurations, API key lifecycle, token storage.
Authorization & Object Access
BOLA across every object type, broken function-level auth for admin endpoints, cross-tenant data access.
Rate Limiting & Abuse
Per-endpoint brute force resistance, resource exhaustion, race conditions, webhook signature validation.
Mass Assignment
Unintended property binding, privilege escalation via request body manipulation, parameter pollution.
Injection via API
SQLi, NoSQLi, command injection through API parameters, headers, and GraphQL arguments.
OWASP API Top 10
Full coverage of the dedicated OWASP API Security standard - all 10 categories.
Webhook & Callback Security
Signature validation, replay protection, IP filtering, malicious webhook registration testing.
Why a scan is not a test
What a scanner misses here
For part of it. But a scanner cannot hold two customers’ tokens and compare what each one is allowed to see. A person can.
Scanner
Finds what is there
- Endpoints reachable with no token
- Known CVEs in the gateway
- Verbose errors and stack traces
- Missing rate limits on obvious routes
- TLS and certificate configuration
Fast, and worth running.
Tester
Finds what is broken
- An object id that returns another tenant’s record
- A field added to a request that the server trusts
- A free-tier token accepted on a paid route
- A GraphQL query nested until the server gives up
- Pagination that walks the whole customer table
This is where the real risk is.
We run both, in that order. Tool output is kept separate from what a tester wrote, so you always know which is which.
Book a Free ConsultationMethodology
How the work is done
Repeatable, documented, and tracked as coverage inside the platform so you can see what has been looked at.
- 01
API Discovery
Review OpenAPI/Swagger spec, GraphQL schema, or proto files. If none exist, we map endpoints from the frontend and mobile apps. 30-60 minute walkthrough.
- 02
Auth Matrix Testing
Test every endpoint with every role (anonymous, user, admin, cross-tenant). Build an authorization gap matrix - this is where most critical findings live.
- 03
Exploit & Chain
Manual exploitation of every finding. Chain auth issues with business logic flaws for real attack narratives.
- 04
Report & Verify
Findings with cURL reproduction commands. Fix guidance per framework. Retest included with every engagement.
Why it matters
What you get out of it
OWASP API Top 10 Coverage
BOLA, broken auth, excessive data exposure, lack of resources & rate limiting, broken function-level auth, mass assignment, security misconfigurations, injection, improper asset management, and insufficient logging.
BOLA / IDOR Specialization
Broken Object Level Authorization is the #1 API vulnerability. We have a dedicated test methodology: map every object ID, test cross-tenant access, and validate every authorization boundary.
REST, GraphQL, gRPC
We test them all. GraphQL gets introspection abuse, query depth attacks, and field-level auth checks. gRPC gets protocol-level fuzzing and service reflection enumeration.
Rate Limiting & Abuse Testing
We test for endpoint-specific rate limits, brute-force resistance, resource exhaustion, and business logic abuse (e.g., coupon enumeration, referral fraud, voting manipulation).
Token & JWT Analysis
JWT algorithm confusion, weak signing keys, token lifetime analysis, refresh token rotation gaps, and OAuth2 scope escalation testing.
Framework-Specific Fixes
Fix guidance in Express, Fastify, Django REST, Spring Boot, Rails API, and Go - with code snippets your devs can copy-paste.
What you receive
Delivered in the platform as the work happens, and exportable as a document whenever you need one.
- API findings report - every endpoint with vulnerabilities, proof-of-concept requests, and fix guidance
- Authorization matrix - visual map of every role × endpoint tested, showing which roles had excessive access
- Rate-limiting assessment - per-endpoint analysis of brute-force and abuse resistance
- JWT/Token audit - algorithm, key strength, lifetime, and rotation analysis
- Video walkthrough - live demo of critical findings with Burp Suite replay
- Re-test validation - confirmation report after fixes
Standards we test against
Coverage is tracked against these inside the platform, so “what did you actually check” has an answer.
- OWASP API Top 10
- OWASP ASVS
- NIST SP 800-204
- PCI-DSS
- GDPR (API)
- ISO 27001
The anatomy of a finding
This is one finding.
Not a report. One finding, with every field it carries and why each field is there. Yours will look like this.
Vexil · Finding
Published- Titlewhat it is, in your engineers’ words
A signed-in customer can read and modify another customer’s orders.
- Affected assetthe specific endpoint of the application
Both the read and the write path are affected.
- GET /api/v2/orders/{id}
- PATCH /api/v2/orders/{id}
- Severitycomputed from the vector, never chosen by hand
- high
- CVSS 3.1 · 8.1
- AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
- CWE-639
- Evidencethe request, the response and screenshots, attached to the finding
A session for customer 8842 returns an order owned by customer 7104.
- GET /api/v2/orders/10318
- Impactwhat it costs you, not what the CVE says
Every order is enumerable from one account, and the write path lets a delivery address be changed. A personal data breach, not only a bug.
- Remediationfor your stack, not “apply vendor patches”
Scope the lookup to the session’s customer so a foreign identifier returns not-found. This is a class of issue, not one endpoint.
- Retesta tester’s verdict, not your self-assessment
Retest passed. Verified by hand, recorded with the date and the tester.
This is the format, not a client’s work - it is written against the demonstration environment we run for the purpose, and a real finding also carries screenshots of the issue alongside the request and response. We don’t publish client findings, redacted or otherwise. If you want to see a real one, email us and we’ll send a redacted sample.
Pricing
What changes the price
Every engagement is quoted on scope rather than hours. These are the four things that move it, and they are what we work through on the call.
Endpoints
How many, documented or not
Auth model
Tokens, scopes, tenancy
Protocols
REST, GraphQL, gRPC
Environments
Staging, production, both
Delivered on the Vexil platform
Findings are filed against the endpoint and method they affect, not against "the API", so the team that owns a route sees only what belongs to them.
See the platformFAQ
Questions about API penetration testing
Do you test GraphQL APIs differently from REST?
Absolutely. GraphQL has unique attack vectors: introspection abuse, query depth/alias/cost attacks, field-level authorization gaps, batching-based brute force, and subscription exhaustion. We test all of them. We also check whether your GraphQL-to-REST resolvers introduce authorization gaps at the data-fetching layer.
We don't have OpenAPI/Swagger docs - can you still test?
Yes, and it is common - undocumented APIs are the normal case rather than the exception. We map endpoints from your frontend and mobile traffic, from any internal docs you have, and from the application itself. Discovery takes longer without a spec, and the scope section of the report names what we enumerated so you can see the coverage rather than assume it. We will also generate a basic OpenAPI spec from what we find.
What's the difference between BOLA and IDOR - and do you test both?
BOLA (Broken Object Level Authorization) is the modern term for IDOR (Insecure Direct Object Reference). We test this extensively - it is the first entry in the OWASP API Security Top 10, and the one automated scanning is least able to find. Our test methodology: for every object ID exposed in your API (user IDs, order IDs, file IDs, etc.), we test whether another user or role can access, modify, or delete it.
Can you test internal/microservice APIs that aren't publicly exposed?
Yes. We can test via VPN, a provided bastion host, or on-site. Internal APIs often have weaker security than public-facing ones - no rate limiting, no auth between services, plain HTTP - because teams assume the network perimeter protects them. After a breach, internal APIs are the attacker's playground. We find those gaps.
How do you handle rate limiting tests without causing a denial of service?
We test rate limits incrementally - starting with low request rates and gradually increasing. We never run denial-of-service attacks. If we find that an endpoint lacks rate limiting, we demonstrate it with a controlled example (e.g., "we enumerated 100 user IDs and accessed their data in 30 seconds") and recommend thresholds. We never take down your production API.
What if we have webhooks or third-party callbacks - do you test those?
Yes. Webhook endpoints are often the least-secured part of an API because they're not documented publicly. We test webhook signature validation, replay protection, IP filtering, and whether attackers can register malicious webhook URLs. Webhook handlers are a common source of high-severity findings, precisely because they are rarely covered by the same review as the public API.
Scope your API penetration testing engagement.
Thirty minutes on a call and you have a fixed price, a testing date and a walkthrough of the platform against your own scope.