Penetration testing
API Penetration Testing
Your API is the real application. We test it directly, with every client-side restriction removed from the path.
Engagements from $5,000 CAD. Free scoping, a fixed price in writing before any work begins, and one retest included.
At a glance
Is this the right test?
- Best when
- The API is the product, or several clients and integrations depend on it.
- Covers
- REST, GraphQL and SOAP endpoints tested role by role, including object and function level authorization, token scope, mass assignment and rate limits.
- You learn
- Which roles can reach data and actions they should not, laid out as an authorization matrix.
Before we start
What we need from you
Scoping settles the details. These are the things that usually decide whether testing can start on the agreed date.
- A schema or collection (OpenAPI, Postman, a GraphQL schema) or, failing that, documentation and example calls.
- Valid tokens for each role and tenant in scope.
- A staging environment, or agreed limits for production including rate limits we must respect.
- Optional: source code for the authorization layer.
Deliverables
What lands in your inbox
- Executive summary
A plain-language account of the risk position, written for the people who will not read the request traces.
- Overall security grade
A single grade derived from the most severe confirmed finding, using the thresholds set out in the report.
- Authorization matrix
Which roles reached which endpoints, including the combinations that should have been refused and were not.
- Detailed technical findings
Every finding with CVSS vector, CWE classification, affected endpoints and full reproduction steps.
- Proof-of-concept evidence
The exact requests and responses demonstrating each finding, ready to paste into a client or a test case.
- Remediation recommendations
Written against the endpoint and the role, and ranked by exploitability, business impact and what to fix first.
- Retest summary
Issued after remediation, confirming what is fixed and what remains.
| Endpoint | Anonymous | User (tenant A) | Admin (tenant A) |
|---|---|---|---|
GET /v1/invoices/{id} | As intended: Denied | As intended: Own tenant only | As intended: Own tenant only |
GET /v1/users/{id} | As intended: Denied | Finding: Any tenant | As intended: Own tenant only |
PATCH /v1/users/{id}/role | As intended: Denied | As intended: Denied | Finding: Any tenant |
POST /v1/exports | As intended: Denied | As intended: Own tenant only | As intended: Own tenant only |
DELETE /v1/webhooks/{id} | As intended: Denied | Finding: Any tenant | As intended: Own tenant only |
See a redacted excerpt from a real finding, and what the full report adds.
Why it matters
What this protects you from
-
The interface is not the boundary
If a rule is enforced only by the app that calls the API, it is not enforced. Attackers call the API directly.
-
Broken object authorization leads the list
It is the first entry in the OWASP API Security Top 10. Changing one identifier in one request can be all it takes, with no tooling.
-
Scanners need help to see an API
Without a schema and valid tokens for each role, automated tools cover very little. Checking whether one role can reach another's data is manual work.
-
Integrations widen the surface
Every partner integration, webhook and service token extends who can reach your data and under what conditions.
Coverage
What we test
-
Object and function level authorization
Whether identifiers can be swapped across users, tenants and roles, tested on every state-changing endpoint in scope.
-
Authentication and token scope
Token type confusion, scope enforcement, expiry and revocation, and whether privileged claims can be influenced by the client.
-
Mass assignment and input handling
Whether unexpected fields are accepted and persisted, plus injection across parameters, headers and request bodies.
-
Rate limiting and resource controls
Whether limits are enforced server-side and whether client-controlled headers can be used to bypass them.
-
Schema and introspection exposure
GraphQL introspection, verbose errors, and documentation endpoints that reveal more surface than intended.
-
Business logic across endpoints
Sequencing, value tampering and race conditions that only appear when endpoints are combined rather than tested alone.
Approach
Three ways to run it
-
Black box
Endpoints discovered from traffic and public documentation, with no schema supplied. Mirrors an external attacker.
-
Grey box
Schema or collection plus test accounts across each role. The most efficient choice, and what we usually recommend.
-
White box
Schema, accounts and source code, so authorization logic can be traced to where it is actually enforced.
Process
How the engagement runs
-
Scoping and threat alignment
We agree endpoints, environments, roles, rate limits and exclusions in writing, then map the surface and its trust boundaries.
-
Enumeration and schema mapping
Full endpoint, parameter and role mapping, including undocumented routes found in traffic or client bundles.
-
Authorization matrix testing
Every role tested against every in-scope endpoint systematically, because this is where the serious findings live.
-
Targeted exploitation
Confirmed exploitation of authorization, injection, logic and rate limiting weaknesses, with evidence captured.
-
Reporting and remediation
Findings written with the exact request and response, so a developer can reproduce them without guessing, and ranked by exploitability, business impact and what has to be fixed first.
-
Retest
After remediation we retest the reported findings, one round, requested within 60 days of the report, and issue a retest summary confirming closure.
Standards
What we test against
- OWASP API Security Top 10
- The primary reference for this work, covering the authorization and object-level failures that dominate real API findings.
- OWASP ASVS
- Verification requirements for authentication, session management and access control, applied at the API layer.
- OWASP Web Security Testing Guide
- Individual test cases for input handling and session management, so coverage is reproducible between engagements.
- NIST SP 800-115
- Overall assessment structure, which is what procurement teams expect to see referenced.