Cybersecurity
API penetration testing
APIs now carry most of an application’s real logic. They also hide the flaws that scanners miss: object-level authorization, tenant isolation and abusable workflows. We test those by hand, one role and one tenant at a time.
Why APIs fail differently
A web page hides things from users by not drawing them. An API cannot hide anything. If the server does not check who is asking for object 4418, anyone who guesses the number gets it. This pattern, called broken object level authorization, leads the OWASP API Security Top 10 and is behind many real-world data exposures.
Multi-tenant SaaS raises the stakes. One missing check can expose every customer’s data to every other customer. Testing for that means building test tenants and attempting to cross between them in every way an attacker could think of.
Who asks for it
-
SaaS product teams
Evidence that tenants cannot see each other’s data.
-
Platform and API teams
Authorization findings with the exact requests that trigger them.
-
Security teams
A map of which endpoints enforce which checks, for use in future reviews.
What is in scope
-
Object-level authorization
Change identifiers, nested references and filters to reach other users’ and tenants’ objects.
-
Function-level authorization
Call administrative and internal functions as ordinary users, including through alternate paths and HTTP methods.
-
Property-level exposure
Look for excessive data in responses and mass assignment of fields clients should not set.
-
Authentication and tokens
OAuth 2.0 and OIDC flows, JWT validation, API keys, token lifetime, refresh and revocation.
-
Resource and rate limits
Brute force, enumeration, expensive queries and abuse of bulk operations.
-
GraphQL specifics
Introspection, query depth and cost, batching, alias abuse and field-level authorization.
-
Business-logic abuse
Out-of-order workflows, replay, race conditions and misuse of legitimate features.
-
Gateway and configuration
Inconsistent policy between gateway and service, shadow and deprecated endpoints, verbose errors.
How the work runs
API testing depends on a good map of the API. Most of the early effort goes into building one.
Map the API
Know every endpoint and who should reach it.
-
1
Inventory
Combine OpenAPI or GraphQL schemas, proxy traffic, client code and documentation to list endpoints, including undocumented ones.
-
2
Authorization matrix
Build a role-by-endpoint matrix of expected access with your team, then use it as the test plan.
Test
Compare what should happen with what does.
-
3
Cross-role and cross-tenant tests
Replay requests with other users’ tokens, identifiers and tenant headers. Record every difference.
-
4
Token and flow analysis
Examine how tokens are issued, validated, scoped and revoked.
-
5
Logic and abuse testing
Replay, reorder and race requests. Test limits and bulk functions.
Report
Make the matrix the deliverable.
-
6
Findings and matrix
Each finding links to the exact requests. The final matrix shows pass or fail per role per endpoint.
-
7
Fix guidance
Centralized authorization patterns rather than endpoint-by-endpoint patches.
-
8
Retest
Re-run the matrix after fixes and add regression test ideas for your pipeline.
What you receive
- Executive summary
- Endpoint inventory, including undocumented endpoints found
- Authorization matrix with test results
- Findings mapped to OWASP API Security Top 10 (2023)
- Reproduction as raw requests and curl commands
- Guidance for centralized authorization checks
- Retest report
Tooling and technique
Tool categories describe how we work. They are not a claim of vendor partnership or certification.
Standards we map to
Mapping findings to a framework is not the same as certification against it.
Before we start
What we need from you
- OpenAPI/GraphQL schema or a Postman collection
- At least two test tenants, with a user at every role in each
- Explanation of how tenancy is determined (token, header, subdomain, path)
- A staging environment, or agreed production limits
- Rate-limit and WAF details
What this service is not
- A load test
- A review of source code (available as a separate white-box assessment)
- A scan of every endpoint with default payloads
What changes afterwards
- You know whether tenant isolation holds under real attempts to break it
- Authorization is checked in one place, not many
- Your CI pipeline gets regression tests for the issues found
What it looks like in practice
Illustrative scenario. Not a real client engagement. No outcomes are claimed.
A pattern we look for. This is an illustrative scenario, not a client case.
- The request
- GET /api/v2/reports/8841 returns a report. The report ID is sequential and the response includes a tenant name.
- The test
- Using a token from tenant A, request report IDs belonging to tenant B. The server returns them because it checks that the token is valid but not that the report belongs to the caller.
- The wider problem
- The same missing check exists on the export endpoint and the PDF endpoint, because each service implemented authorization separately.
- The fix
- Move ownership checks into a shared policy layer, add tests that attempt cross-tenant access for every route, and monitor for sequential-ID scanning.
Questions people ask
Do you need access to source code?
No. Gray-box testing with schemas and test accounts finds most authorization issues. Source access speeds things up and finds more, and we offer it as a white-box option.
Can you test internal service-to-service APIs?
Yes, from a defined internal position. We look at service authentication, network trust assumptions and what a compromised service could call.
What is BOLA?
Broken object-level authorization: the server accepts an identifier from the client and does not check that the caller is allowed to access that object. It is the most commonly reported API flaw.
Is GraphQL harder to secure?
It is different. A single endpoint serves many queries, so authorization must be checked at field and object level, and expensive queries must be limited. We test both.
Related
-
Web application penetration testing
Manual testing of authentication, authorization, session handling, input handling and business logic in web applications.
-
AI agent security
Review agents that plan and call tools: identity, tool permissions, approvals, memory, isolation and audit.
-
Identity governance
Joiner-mover-leaver processes, access reviews, role design and entitlement cleanup for workforce and application access.
Need to understand your security exposure?
Speak with a security expert
Talk through your environment and goals. We reply to scope the work before anything is tested.
Speak with a security expertPlan an assessment
Answer a few questions and get a structured preliminary scope you can send us.
Use the plannerUnder attack right now?
Call the US office and tell us what you are seeing. Do not wait for a form reply.
Incident response