Object authorization
Check access to individual records, files, messages, and invoices. A valid account should not grant access to another user's private objects.
REST, GraphQL, and connected services
API penetration
API penetration
testing.
API penetration testing checks who can call each endpoint, what they can read or change, and where data flows, including object and function-level authorization. Balhence tests REST and GraphQL APIs by hand, maps relevant findings to the OWASP API Security Top 10, and provides evidence and practical fixes.
Authorization firstObjects, functions, properties, roles, and tenants
Fits your stackREST, GraphQL, webhooks, gateways, and workers
Checked by a testerConfirmed findings, request evidence, and clear impact
Agreed safety rulesScope, rate limits, contacts, and stop conditions
What we test
What we test in REST and GraphQL APIs
We map normal access first, then test the rules across users, roles, organizations, and workflows. A tester checks each finding before it reaches your report.
Function authorization
Check restricted and administrative actions on the server, including older API versions and operations the interface doesn't show.
Property authorization
A caller may be allowed to edit a record without being allowed to change every field. We check writable properties and sensitive response fields.
Tenant isolation
Follow access through organization switches, invitations, shared resources, and ownership changes. Legitimate sharing belongs in the test model too.
Data exposure
Look at responses, errors, caches, exports, and metadata for information the caller shouldn't receive.
Include gateways and shared caches in the boundary when they handle private API responses. The private response caching field note shows why response reuse needs its own access checks.
Business logic
Check the rules around approvals, credits, inventory, and other multi-step actions, including repeated or overlapping requests within agreed limits.
Interfaces and identities
API testing across protocols and caller identities
Users aren't the only callers. We account for service accounts, webhooks, background jobs, and identity providers when agreeing on what to test.
REST APIs
Check routes, methods, versions, and content types, including filtering, pagination, batch operations, and errors. Equivalent endpoints should enforce the same rules.
Include form-validation and lookup helpers in the inventory, even when their replies are only yes or no. Our server-side validation and data exposure story explains why the server must control the rule behind that answer.
GraphQL APIs
Review schema exposure, resolver permissions, field access, mutations, and subscriptions. Batching and complexity checks stay within agreed resource limits.
Webhooks and callbacks
Check signatures, event secrets, retries, destinations, and how incoming events change product state. Repeated events should not quietly repeat a sensitive action.
OAuth and OIDC
Review redirects, consent, scopes, claims, PKCE, and token handling. Check that each login and authorization flow stays tied to the intended client and session.
API keys and tokens
Check what keys can access, how they expire or get revoked, and whether credentials stay separate between environments. Review token validation and fallback behavior.
Service accounts
Review machine permissions, client credentials, delegated access, and secrets. A service account still needs a defined purpose and the right tenant context.
Rate and resource limits
API rate limits and resource control testing
We use low-volume, bounded checks for weak rate and resource controls. Volumetric denial-of-service testing needs a separate agreement and a safe method.
Rate and quota controls
Low-volume checks for identity, endpoint, tenant, IP, and token limits, including alternate methods, batch features, and distributed control inconsistencies.
Resource consumption
Bounded tests of expensive filters, search, uploads, exports, GraphQL complexity, pagination, asynchronous jobs, and fan-out behavior.
Automation and enumeration
Account, object, invitation, reset, and identifier discovery where response differences or missing friction enable targeted abuse.
Downstream trust
Unsafe consumption of user-controlled URLs, files, templates, event fields, and service responses that can shift risk beyond the public API boundary.
Mapped to the OWASP API Security Top 10
The OWASP API Security Top 10 (2023) provides the risk taxonomy. Relevant coverage includes:
- Broken object-level authorization (BOLA) and broken function-level authorization (BFLA).
- Broken authentication, including token issuance and revocation.
- Broken object property level authorization, including excessive response data and unauthorized field changes.
- Unrestricted resource consumption and access to sensitive business flows, assessed within agreed safe limits.
- Server-side request forgery, security misconfiguration, inventory management, and unsafe consumption of APIs.
Injection is assessed where relevant to the implementation; it is not a separately named category in the 2023 API list. Web and API coverage can be scoped together through web application testing or SaaS testing.
Planning the scope
Planning your API penetration testing scope
The number of endpoints is only part of the picture. Roles, integrations, workflows, and access details help us plan the test. India-based API teams can use the India VAPT brief to settle remote access, IST coordination and data rules.
| Input | What to provide | Why it changes coverage |
|---|---|---|
| Interfaces | Base URLs, REST versions, GraphQL endpoints, gateways, webhooks, and callback receivers | Equivalent operations may enforce different controls across routes and protocols |
| Documentation | OpenAPI or Swagger files, GraphQL schema access, collections, integration guides, and known inventories | Reliable inventories preserve time for deeper manual scenarios |
| Identities | User roles, tenant types, administrators, partners, service accounts, API keys, and OAuth clients | Authorization testing grows with meaningful identity and tenant combinations |
| Workflows | Approvals, payments, credits, invitations, exports, uploads, provisioning, and irreversible actions | Business impact depends on state, sequence, and ownership rules |
| Integrations | Identity providers, payment systems, storage, queues, third-party APIs, and event consumers | Trust changes when data crosses system and ownership boundaries |
| Environment | Staging or production, test data, monitoring, rate guidance, deployment freeze, and support contacts | Environment readiness affects both safety and productive test time |
API caller and permission worksheet
A useful inventory connects each interface to its callers and intended data access. This synthetic billing example helps engineers describe the scope without sharing production credentials. List active versions and any shared identity controls alongside these rows.
| Interface and caller | Expected access | Scope input |
|---|---|---|
| REST / customer member | Read that customer's permitted invoice records | OpenAPI inventory, member account, and synthetic invoices |
| GraphQL / customer administrator | View billing fields assigned to the administrative role | Schema, role policy, and representative billing queries |
| Webhook / payment sandbox | Update only the agreed payment workflow | Controlled event source and documented event states |
| Worker / service account | Process assigned jobs within its environment and tenant permissions | Credential lifecycle policy and synthetic queued jobs |
Mark missing documentation, unavailable callers, and excluded providers before estimating effort. The web and API scoping guide helps turn this inventory into an agreed boundary. Use the pentest report checklist to agree how assessed and unavailable areas will be recorded.
During the test
How API penetration testing works
Documentation and a conversation with your engineers help establish the expected behavior. We test against that and keep you informed as findings are confirmed.
Agree on the scope
Confirm the APIs, accounts, sensitive data, workflows, exclusions, and questions you need the test to answer.
Understand normal access
Map what each role and organization should be able to access, then record normal requests for comparison.
Check for weaknesses
Test whether permissions and workflow rules hold up when requests change, within the agreed safety limits.
Confirm and explain findings
Reproduce each reported issue, document its impact, and explain the fix. Raise urgent issues through the agreed channel during testing.
Getting ready
API pentest access and environment readiness
A stable environment, working test accounts, and clear testing rules help us spend the time on your API.
Readiness checklist
What to have ready
- A stable, representative environment
- Written authorization and named asset ownership
- Current API documentation or a known inventory
- Test identities for each relevant role and tenant
- Dedicated records, files, and workflow data
- A contact who can resolve access and environment questions
- Monitoring, allowlisting, and escalation channels prepared
Before testing
What we'll confirm together
- Signed agreement and finalized statement of work
- Rules of engagement with rate and concurrency boundaries
- Confirmed included hosts, versions, roles, and integrations
- Stop conditions and urgent communication contacts
- Instructions for customer data and sensitive evidence
- Authorization for any third-party service explicitly included
- Known unavailable features or environment differences documented
Scope and safety
API pentest authorization and safety controls
The signed scope and rules of engagement name the systems, methods, rate limits, evidence handling, contacts, and exclusions.
Authorization and safety
Controls written into the rules of engagement
- Exact systems, interfaces, identities, and testing window
- Permitted production techniques and test-data requirements
- Request rates, parallelism, and resource-consumption limits
- Approval rules for webhook destinations and external callbacks
- Evidence retention and secure handling expectations
- Immediate escalation thresholds and pause conditions
Excluded unless agreed
Work that needs separate scope or approval
- Denial-of-service, stress, or capacity testing
- Third-party systems without written authorization
- Social engineering, phishing, or physical testing
- Source-code review and architecture review
- Mobile, thick-client, cloud, or external infrastructure testing
- Destructive actions or access to real customer records
- Compliance certification or guaranteed audit acceptance
API pentest evidence for SOC 2
Include the APIs, caller roles, integrations, and tenant boundaries named in your review. Our SOC 2 penetration testing page explains how scope, findings, and re-test records can support the audit.
Deliverables
What you get from an API pentest
Each finding names the affected accounts and resources, explains what we observed, and includes the evidence your engineers need. We separate demonstrated impact from assumptions. See our guide to a useful pentest report for what to look for in a sample.
- 01A summary for leadershipThe main risks, their effect on your product, suggested priorities, and the limits of the test.
- 02Technical findingsAffected routes, identities, preconditions, request and response evidence, reproduction steps, impact, and targeted remediation guidance.
- 03Coverage recordTested interfaces, roles, tenants, workflows, constraints, exclusions, and material environment limitations.
- 04Remediation supportA findings walkthrough and one bounded re-test when included in the agreement, with clear fixed, partial, open, or not re-tested status.
Planning the schedule
API penetration testing timelines and effort
We'll propose a test window after reviewing the scope and confirming access. These are the details that affect the work.
Identity combinations
More roles, tenant types, service accounts, and delegated permissions mean more access relationships to check.
Workflow depth
A payment or approval flow takes more time to understand and test than a simple lookup. Background jobs add another step to follow.
Documentation and test data
Current API inventories, stable schemas, and useful test data reduce time spent on discovery and troubleshooting.
Integration count
Identity providers, webhooks, storage, queues, partner APIs, and downstream services add distinct trust boundaries and failure modes.
Environment constraints
Production safeguards, allowlisting, rate ceilings, maintenance windows, deployments, and unavailable features can shape sequencing and depth.
Reporting needs
Tell us who will read the report and what they need from it. Customer reviews, engineering work, and framework mapping can require different detail.
Related services
API-only or combined web and API penetration testing
Focus on the API when services, integrations, and access rules are your main concern. Include the web app when browser behavior, sessions, uploads, and user workflows are part of the same risk.
Web application penetration testing
Cover browser behavior, sessions, user journeys, client and server trust, and application-specific business logic.
Explore web application testingSaaS penetration testing
Assess the product's tenant boundaries, customer administration, integrations, and shared web and API workflows together.
Explore SaaS testingNot sure what to include?
The scope planner helps you gather your app details, roles, integrations, and reason for testing before a call.
Build a draft scopeAPI pentest FAQ
API penetration testing FAQ
Common questions about documentation, accounts, production testing, and re-tests.
What affects the cost of an API penetration test?
The work depends on caller identities, tenant models, API versions, workflow depth, integrations, and the quality of available documentation. Endpoint count alone misses these differences. We agree on coverage, effort, deliverables, exclusions, and any re-test window before testing. The API pentest cost and scope guide explains how to compare quotes.
How far ahead should we plan the test?
Share the release or customer-review deadline during scoping. The schedule needs room for access setup, testing, report review, engineering fixes, and any agreed re-test. We confirm availability and the test window after understanding the API; a submitted enquiry does not reserve a start date.
Do you need API documentation?
Documentation is strongly preferred but not always required. An OpenAPI file, GraphQL schema, collection, or current endpoint inventory reduces discovery time and helps reserve effort for authorization and business-logic testing. Undocumented interfaces should be identified during scoping so the test window reflects the extra discovery work.
Can you test GraphQL and REST in one engagement?
Yes, when both interfaces are included in the written scope. Testing considers shared identity and data controls as well as protocol-specific behavior such as resolver authorization, field access, batching, methods, content types, and alternate versions.
What test accounts are needed?
Provide controlled identities for each meaningful role and at least two isolated tenants when tenant boundaries are in scope. Service accounts, API keys, OAuth clients, and delegated roles should be included when they represent real callers. Test records should be safe to create, modify, and delete within agreed limits.
Can production APIs be tested?
Yes, when the asset owner authorizes production testing and the rules of engagement define safe requests, rates, data handling, monitoring, contacts, and stop conditions. Riskier resource-consumption or destructive scenarios remain excluded unless they have separate written approval and a safe test method.
Does testing include rate limits?
It can include bounded, low-volume checks for missing or inconsistent controls. Capacity, stress, and denial-of-service testing are different activities and are excluded unless separately authorized with safeguards designed for that purpose.
How are urgent findings communicated?
The rules of engagement name the severity threshold, communication channel, recipients, and pause conditions. A qualifying finding is escalated through that channel during testing rather than held until the final report.
What happens during the re-test?
When included in the agreement, the bounded re-test checks agreed fixes against the original evidence and relevant control boundaries. The update records whether each item is fixed, partially fixed, not fixed, or not re-tested. New features and unrelated changes need a separate scope.
Can I read an example of workflow-focused testing?
The redacted evidence-gated workflow story explains why a recorded submission is different from an approved result, and why that distinction matters in an API report. It is an anonymized educational reconstruction with explicit evidence limits, not a claim that a customer's fix has been deployed.
Plan your API test
Plan your API penetration testing scope.
Start with the interfaces, roles, integrations, and deadline. A short description is enough for the first conversation; do not send API keys, tokens, or customer data.