Web Application Testing
Test modern web applications for logic flaws, auth issues, and exploitable vulnerabilities.
View service detailsAPI Security Testing · Central Illinois
Your API has no UI to hide behind. Every endpoint is the front door.
The web application enforces what the interface allows. The API enforces what it was told to enforce, one endpoint at a time, and it only takes one endpoint that forgot to check ownership. Broken object-level authorization is the most common serious API finding in the industry and it is invisible to anyone testing with a single account.
What api security testing actually covers
API security testing is a systematic assessment of every endpoint your service exposes, tested directly rather than through a client. We work from your specification where one exists — OpenAPI, a GraphQL schema, a gRPC proto — and from traffic capture where it does not, because the endpoints that never made it into the documentation are consistently the ones with the weakest controls.
The core of the work is authorization, tested combinatorially. Every endpoint is exercised with every role, with tokens belonging to other users, with identifiers belonging to other tenants, and with no token at all. This is tedious and it is exactly where the severe findings live: an endpoint that validates that you are authenticated but never checks whether the record you asked for is yours.
Beyond authorization, we test the things that only matter at the protocol level. Mass assignment where a request body sets fields the client should never control. Excessive data exposure where the response includes columns the interface filters out but the API returns anyway. GraphQL introspection, query batching, and nested query depth. Token handling: signature validation, algorithm confusion, expiry, revocation, and scope enforcement in OAuth flows.
When you need this test
The API is public or partner-facing
Once third parties integrate directly, your API contract is your attack surface and there is no interface layer softening what gets sent to it.
It is the backend for a mobile app
Mobile clients are fully inspectable, so the protocol is public whether you documented it or not. Assume every endpoint the app calls is known to an attacker.
You are multi-tenant
Tenant isolation in an API is enforced by a check on every single endpoint. Coverage has to be complete, and the only way to know it is complete is to test every endpoint from another tenant's session.
Endpoints ship faster than documentation
If your specification is out of date, undocumented endpoints exist. Those endpoints were built quickly, reviewed less, and are still reachable.
You moved to microservices
Service-to-service trust and gateway authorization are where authorization assumptions quietly break. An internal service that trusts a header is a common and serious finding.
What is in scope, and what is not
Included by default
- Object-level authorization across every endpoint, user, and tenant boundary
- Function-level authorization: role enforcement on privileged and administrative operations
- Authentication and tokens: JWT validation, OAuth 2.0 flows, API keys, refresh and revocation
- Mass assignment, excessive data exposure, and unsafe parameter binding
- GraphQL specifics: introspection, batching, aliasing, and query depth and complexity limits
- Rate limiting, resource consumption, injection, and server-side request forgery
Excluded unless contracted
- Sustained denial-of-service and volumetric load testing
- The web or mobile clients that consume the API, which are separate assessments
- Underlying host and network infrastructure
- Third-party APIs you consume but do not control
Methodology, phase by phase
Every engagement follows the same documented arc. The percentages below describe how testing time is typically distributed — the balance shifts with what we find, but the phases do not change.
Scoping and endpoint inventory
Before testing beginsWe build the real endpoint list. Your specification is the starting point, not the boundary — we supplement it with traffic capture from live clients, route enumeration, and GraphQL introspection, because undocumented endpoints are both common and disproportionately vulnerable.
- Import OpenAPI, GraphQL schema, gRPC proto, or Postman collections where available
- Traffic capture from live clients to identify endpoints missing from the specification
- Provision tokens for every role and at least two distinct accounts and tenants per role
- Confirm rate limits, fraud controls, and any endpoints that trigger real-world side effects
Authentication and token analysis
Roughly 20% of testing timeBefore authorization can be tested meaningfully, we establish what a token actually proves. That means examining how tokens are issued, validated, scoped, and revoked, and whether the server genuinely verifies what it claims to verify.
- JWT analysis: signature verification, algorithm confusion, claim tampering, expiry and clock handling
- OAuth 2.0 and OIDC flow testing including redirect validation, PKCE, and scope enforcement
- Token lifecycle testing: revocation on logout and password change, refresh token reuse, session fixation
- API key handling, transmission, and whether keys carry the privileges they should
Authorization testing across the endpoint matrix
Roughly 40% of testing timeThe largest phase, and the reason to run the engagement. Every endpoint is called with every role, cross-user identifiers, and cross-tenant identifiers. Complete coverage is the point — a 95% correct authorization model has exactly the same outcome as a broken one.
- Broken object-level authorization testing: every object reference accessed from a session that should not reach it
- Broken function-level authorization: privileged and administrative endpoints called from unprivileged roles
- Cross-tenant isolation testing across the full endpoint matrix
- Unauthenticated access testing against every endpoint, including those assumed to be internal-only
Data handling, injection, and resource abuse
Roughly 25% of testing timeWith authorization mapped, we test what the API accepts and what it returns. Requests are manipulated to set fields the client should not control, and responses are reviewed for data the interface hides but the API sends anyway.
- Mass assignment testing against every write endpoint, targeting role, tenant, price, and status fields
- Response review for excessive data exposure, including fields the client filters but the server returns
- Injection testing across parameters, headers, and structured bodies, plus server-side request forgery
- Rate limiting and resource consumption testing, including GraphQL query depth, complexity, and batching abuse
Reporting and retest
5 business days after testing endsYou receive the endpoint coverage matrix alongside the findings, so you can see exactly what was tested rather than inferring it. Authorization findings are grouped by root cause, because thirty broken endpoints usually trace back to one missing middleware.
- Findings with complete request and response captures, reproducible with curl
- Endpoint coverage matrix showing every endpoint, role, and test outcome
- Root-cause grouping so systemic authorization gaps are fixed once rather than thirty times
- Free retest of remediated findings within 90 days
Standards this maps to
Auditors, insurers, and enterprise security reviewers all ask which methodology a test followed. These are the published frameworks our process is built on, and the report names them explicitly.
- OWASP API Security Top 10
- The 2023 edition is the coverage baseline. Every category is exercised explicitly and the report maps each finding to its API Top 10 identifier.
- OWASP WSTG
- The Web Security Testing Guide supplies the underlying test procedures for injection, session management, and input handling that apply equally to API endpoints.
- PTES
- The Penetration Testing Execution Standard defines the engagement arc we follow: pre-engagement, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post-exploitation, reporting.
- CVSS v4.0
- Every finding carries a CVSS v4.0 vector so the base score is reproducible, plus a separate business-impact rating, because a 9.8 on a decommissioned host is not your biggest problem.
What you receive
A human writes your report. Not a scanner export with a cover page, and not a template with your logo dropped into it.
- Endpoint coverage matrix
- Every endpoint crossed with every role and test type, with results. You can see what was tested and what was not, instead of trusting that the coverage was complete.
- Findings with reproducible requests
- Each finding includes a curl command that reproduces it. Your developers verify the issue and their fix in seconds rather than rebuilding our setup.
- API Top 10 mapping
- Findings mapped to OWASP API Security Top 10 categories, which is the framework your enterprise customers and auditors are most likely to ask about by name.
- Root-cause analysis
- Authorization findings grouped by underlying cause. Thirty vulnerable endpoints are usually one missing middleware, and fixing the middleware is the actual remediation.
- Undocumented endpoint inventory
- Every endpoint we found that was not in your specification, which is frequently the most immediately useful part of the report for the engineering team.
- Attestation letter and retest report
- A shareable summary for customers and auditors, plus verification of your fixes within the included 90-day retest window.
Typical scope and duration
- Typical testing window
- 5–10 business days
- Report delivery
- 5 business days after testing ends
- Total elapsed time
- 3–4 weeks from kickoff
- Common scope size
- 50–300 endpoints, 2–5 roles
- Access required
- Two accounts per role, two tenants, and a specification if one exists
- Retest window
- 90 days, included
What drives the price
We quote a fixed fee after a short scoping call. No hourly billing, no change orders mid-engagement. These are the variables that move the number:
- Endpoint count, since authorization testing scales with endpoints multiplied by roles rather than with endpoints alone
- The number of roles and whether multi-tenancy adds a cross-tenant testing pass
- Whether a current specification exists, because building the inventory from traffic capture takes real time
- Protocol mix — GraphQL and gRPC each require test approaches that REST tooling does not cover
- Whether service-to-service and internal gateway authorization are in scope alongside the public surface
Frequently asked questions
How long does an API penetration test take?
Most API engagements run 5 to 10 business days of active testing, with the report 5 business days later. The driver is endpoints multiplied by roles, not endpoint count alone: 60 endpoints with 5 roles is more work than 200 endpoints with a single role, because authorization testing is combinatorial.
Do you need an OpenAPI specification?
It helps and it is not required. We build the endpoint inventory from your specification plus traffic capture, route enumeration, and GraphQL introspection. Working without a specification costs time in the inventory phase, and it also tends to surface undocumented endpoints — which are consistently among the weakest.
What is BOLA and why do you emphasize it?
Broken object-level authorization is when an endpoint confirms you are logged in but never confirms the record you requested belongs to you. Change an ID in the request and you read someone else's data. It is the most common serious API vulnerability, it is trivial to exploit, and a scanner cannot find it because the scanner does not know which records you are supposed to own.
Can you test GraphQL and gRPC?
Yes. GraphQL testing covers introspection exposure, query depth and complexity limits, batching and aliasing abuse for rate-limit bypass, and per-resolver authorization — the last of which is where GraphQL implementations most often fail. gRPC is tested from the proto definitions with the same authorization matrix approach.
How many test accounts do you need?
At minimum two accounts per role and, for multi-tenant systems, two separate tenants. Two accounts at the same privilege level is what makes horizontal authorization testing possible at all — with a single account there is no other user's data to attempt to reach.
Will testing pollute our production data?
We prefer staging for exactly this reason. Where production testing is necessary, we agree on constraints in advance, tag any records we create so they are trivially identifiable, and avoid endpoints with real-world side effects such as outbound email, payments, or shipping unless you explicitly want them tested.
Related engagements
Mobile Application Testing
Evaluate mobile apps and connected APIs for insecure data flows and client-side abuse paths.
View service detailsExternal Penetration Testing
Assess internet-facing assets to identify exploitable weaknesses before attackers do.
View service detailsNot sure this is the right test?
Tell us what you are trying to prove and to whom. A twenty-minute scoping call is usually enough to determine which engagement answers the question, and we will say so if the answer is a cheaper one.