Object authorization
Cross-user and cross-tenant access to records, files, exports, messages, invoices, and nested resources through predictable, leaked, or substituted identifiers.
API penetration testing
Find the API flaws that appear only when identities, objects, and workflows collide.
Manual testing for REST, GraphQL, webhooks, and machine identities, shaped around your architecture and threat model. Every actionable finding is validated and written for remediation.
Authorization firstObjects, functions, properties, roles, and tenants
Architecture awareREST, GraphQL, webhooks, gateways, and workers
Manual validationVerified paths, request evidence, and practical impact
Safe by agreementExplicit boundaries, rate limits, contacts, and stop rules
Core API coverage
Test the controls between a valid request and an unauthorized outcome.
Coverage follows real trust boundaries and data flows. Automated discovery supports the work, while manual scenarios test how controls behave across roles, states, and chained operations.
Function authorization
Restricted operations, administrative routes, hidden methods, alternate API versions, workflow transitions, and privilege checks enforced only by a client.
Property authorization
Mass assignment, over-posting, excessive response fields, writable state flags, hidden attributes, and field-level access that differs by role or tenant.
Tenant isolation
Organization switches, team hierarchies, invitations, ownership changes, delegated administration, shared resources, and identifiers that cross trust boundaries.
Data exposure
Responses, errors, caches, logs, exports, introspection, metadata, and alternate representations that reveal more information than the requesting identity needs.
Business logic
Sequence bypass, replay, duplicate execution, approval abuse, inventory or credit manipulation, race conditions, and assumptions made between dependent services.
Interfaces and identities
Follow every path that can act on data.
No single protocol defines the whole attack surface. The scope maps interactive clients, machine callers, asynchronous events, and identity providers to the controls they rely on.
REST APIs
Routes, methods, versions, content types, identifier handling, filtering, pagination, batch operations, error states, and inconsistent enforcement across equivalent endpoints.
GraphQL APIs
Schema exposure, resolver authorization, node and edge traversal, aliases, batching, mutations, subscriptions, complexity limits, and field-level data access.
Webhooks and callbacks
Signature validation, replay resistance, destination changes, event secrets, retry behavior, state confusion, server-side requests, and trust in inbound event data.
OAuth and OIDC
Authorization flow binding, redirect handling, scopes, claims, consent, token audience, refresh behavior, PKCE, discovery, session linkage, and client boundaries.
API keys and tokens
Key scope, rotation and revocation, leakage paths, environment separation, token validation, expiry, replay, audience confusion, and fallback authentication behavior.
Service accounts
Machine identity privileges, client credentials, workload trust, impersonation, delegated access, secret handling, tenant context, and lateral actions between services.
Abuse resistance
Assess resource controls without turning the test into a load event.
Rate and resource testing is designed to prove control weaknesses with minimal traffic. Volumetric denial-of-service testing is excluded unless a separate, explicit agreement defines 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.
Scoping inputs
Define the API surface before the test window.
A useful scope describes more than endpoint count. These inputs expose the identity combinations, integration paths, and business states that determine the work.
| 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 |
Testing workflow
Move from inventory to verified impact.
The exact techniques depend on the architecture. The engagement keeps authorization, evidence, and communication explicit from the first request through remediation.
Model the surface
Confirm interfaces, identities, data classes, trust boundaries, sensitive workflows, exclusions, and the outcomes the assessment needs to support.
Establish baselines
Map expected access by role and tenant, then record normal requests for object, function, property, and state comparisons.
Test abuse paths
Mutate identities, identifiers, properties, order, timing, transport, and integration assumptions while respecting agreed safety limits.
Validate and report
Reproduce actionable findings, capture concise evidence, explain business impact, provide remediation guidance, and communicate urgent issues through the agreed channel.
Engagement readiness
Prepare safe access before the first test request.
A stable environment, representative identities, and explicit operating rules protect both test depth and the systems being assessed.
Readiness checklist
What helps the test start productively
- 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
Prerequisites that protect the engagement
- 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
Engagement boundaries
Write the safety model before testing starts.
Authorization is specific. Included systems, techniques, rates, evidence handling, escalation, and exclusions belong in the signed scope and rules of engagement.
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
Deliverables
Evidence an engineer can verify and use.
The report separates observed facts from impact analysis. Findings explain the affected identity, object or function, tenant boundary, required preconditions, and the smallest reliable reproduction path.
- 01Executive contextRisk themes, affected business capabilities, priority, and practical decision support without overstating assurance.
- 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.
Timeline drivers
The schedule follows test depth, access combinations, and environment readiness.
A working window is proposed after scope review. It is not inferred from endpoint count alone, and it is not promised before the relevant dependencies are confirmed.
Identity combinations
Roles, tenant types, service accounts, OAuth clients, delegated access, and administrative hierarchies create the meaningful authorization matrix.
Workflow depth
Payments, approvals, exports, provisioning, invitations, asynchronous jobs, and multi-step state changes require scenario-led testing.
Surface quality
Accurate inventories, current documentation, stable schemas, and representative test data reduce discovery and troubleshooting overhead.
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
Engineering remediation, customer assurance, framework mapping, evidence review, and stakeholder walkthroughs require different presentation depth.
Choose the right boundary
API-only scope or an end-to-end application assessment?
An API engagement fits when the interfaces, machine identities, and integration trust are the primary concern. Include the web application when browser state, client-enforced controls, session behavior, uploads, or user journeys materially affect 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 testingWeb and API pentest sprint
Assess the customer-facing application and its supporting APIs as one connected system with shared identities and workflows.
Explore the services hubNot sure which boundary fits?
Use the scope planner to map the product, identities, integrations, trigger, and reporting need before a scoping conversation.
Build a draft scopeAPI pentest FAQ
Questions to settle before authorization.
Clear answers protect test depth, safety, and the usefulness of the final evidence.
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?
The agreed fixes are checked against the original reproduction path and relevant bypass conditions. 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.
Scope the API boundary
Bring the interfaces, identities, tenants, integrations, and reason for testing.
The first step is a written, reviewable scope. Testing starts only after the agreement, authorization, boundaries, and safety rules are complete.