Challenge the authorization behind every object and function.
API risk is rarely limited to malformed input. The more consequential paths often involve valid requests made in the wrong identity context, operations exposed beyond their intended role, or business rules that can be bypassed through direct sequencing. Testing follows the API as a system rather than treating endpoints as isolated URLs.
SCOPE → DISCOVER → TEST → VALIDATE → REPORT → RETEST
ASSESSMENT BOUNDARY
What is being assessed?
The engagement boundary is defined by systems, identities, workflows and restrictions—not only a list of URLs or assets.
- REST, GraphQL, SOAP and gRPC APIs included in scope
- Authentication and token/session lifecycle
- Object-level and function-level authorization
- Role, tenant, permission and ownership boundaries
- Input validation, injection and excessive data exposure
- Safe abuse, resource-control and business-logic validation
- OpenAPI/Swagger definitions, Postman collections and API documentation when supplied
What Botnet tests.
Testing is manual-led and supported by appropriate tooling. Findings are manually validated before reporting. Coverage follows reachable trust decisions and agreed risk; source-code review is not implied unless explicitly scoped.
Object access
Ownership, tenant and record boundaries across read and write operations.
Function access
Administrative and sensitive operations tested from lower-privilege identities.
Token security
Issuance, validation, expiry, audience, rotation and misuse conditions within the agreed design.
Data and models
Over-posting, excessive response data, schema assumptions and unsafe server-side processing.
Workflow abuse
Order, replay, concurrency, limits and direct invocation of operations normally mediated by a client.
Protocol behavior
Protocol-specific trust, parsing and configuration behavior across GraphQL, SOAP or gRPC when in scope.
How the work progresses.
- 01
Ingest
Review definitions, collections, environments, roles and expected workflows.
- 02
Normalize
Map operations, identities, objects and trust boundaries into a test model.
- 03
Challenge
Test authorization, state, input and server behavior through controlled requests.
- 04
Correlate
Connect API conditions to associated web, mobile, identity or cloud context where included.
- 05
Evidence
Capture reproducible requests and responses without unnecessarily retaining sensitive data.
- 06
Re-test
Deliver findings, discuss fixes and use the included re-test for agreed remediated findings.
EVIDENCE + ACTION
What the customer receives.
- API attack-surface and role summary
- Reproducible request/response evidence with sensitive values minimized
- Authorization and business-logic findings
- Severity/risk context and technical remediation guidance
- Scope and coverage limitations
- Stakeholder readout and one re-test result for agreed remediated findings
Evidence over assumption.
01Authorization testing across roles and objects
02Direct testing of business operations outside the normal client
03Use of definitions as inputs—not as proof of deployed behavior
04Cross-surface reasoning where an API supports web or mobile applications
Before scoping.
Is API documentation required?
No, but accurate OpenAPI/Swagger definitions or Postman collections can improve coverage and reduce discovery time. Deployed behavior is still validated independently.
Can GraphQL be included?
Yes where applicable and confirmed in scope. Testing depth depends on the schema, identity model and agreed environment.
Will the assessment test rate limits?
Rate and abuse controls can be assessed within safe thresholds agreed during scoping. Load or denial-of-service testing is not implied.
Define the target, constraints and required evidence.
An assessment request starts a scoping conversation. It does not authorize testing. Work proceeds only after scope acceptance, executed authorization/SOW and kickoff.