API Testing
How ModernPentest tests REST APIs using OpenAPI specifications
Overview
When you enable the API surface for your application, we fold your endpoints into the asset map and reason over them the same way we do web pages. Providing an OpenAPI specification gives us a deeper, more complete map — and more thorough testing.
How an API pentest works
OpenAPI analysis & recon
Recon parses your specification and probes the API — extracting endpoints, methods, parameters, auth requirements, and data models — and adds them to your asset map.
Auditing
The auditor reads the mapped endpoints and their relationships and emits prioritized investigations — object-level authorization, broken auth, injection, and more.
Proving
Provers confirm each investigation by actually exploiting it — establishing a baseline, then fuzzing IDs, replaying tokens, or injecting payloads to demonstrate impact.
Consolidation & Reporting
Findings are deduplicated across endpoints, validated, enriched with API-specific context, and compiled with remediation guidance.
Stage 1: OpenAPI Analysis
When you provide an OpenAPI (Swagger) specification, we extract:
Endpoint Information
- All paths and HTTP methods
- Path parameters (e.g.,
/users/{id}) - Query parameters with types
- Request body schemas
Authentication Details
- Security schemes (Bearer, API Key, OAuth)
- Per-endpoint authentication requirements
- Scopes and permissions
Data Models
- Response schemas
- Object relationships
- Required vs optional fields
No OpenAPI spec? We can still test your API through reconnaissance, but coverage will be more limited. We recommend providing a spec for best results.
How the auditor targets endpoints
The auditor reads your mapped endpoints by functionality and decides what each warrants:
| Group | Endpoints | What the auditor probes for |
|---|---|---|
| Authentication | /login, /logout, /token | Auth bypass, session security |
| User Resources | /users/*, /profile/* | BOLA, privilege escalation |
| Data Resources | /products/*, /orders/* | Authorization, injection |
| Admin Functions | /admin/*, /settings/* | Access control, privilege escalation |
Reasoning over the whole map means the auditor understands what each endpoint is for — so a prover testing /users/:id knows to attempt cross-tenant access, not just malformed input.
What provers test
The techniques below are what provers run when an auditor investigation calls for them.
Authentication & sessions
Provers test authentication security:
JWT Security
- Algorithm confusion attacks
- Signature verification bypass
- Token expiration handling
- Claims manipulation
Session Management
- Token revocation effectiveness
- Concurrent session handling
- Session fixation
- Token binding
Authentication Bypass
- Missing authentication
- Weak authentication
- Token replay attacks
Object-level authorization (BOLA)
Provers test object-level authorization (OWASP API1:2023):
Horizontal Access
- Accessing other users' resources
- ID enumeration attacks
- Cross-account data access
Vertical Access
- Regular user accessing admin resources
- Privilege escalation through API
Testing Methodology
- Establish baseline with valid credentials
- Attempt access with different user credentials
- Test with no credentials
- Fuzz object IDs
Injection
Provers test for injection vulnerabilities:
SQL Injection
- Parameter injection
- JSON property injection
- Error-based detection
- Time-based blind detection
NoSQL Injection
- MongoDB operator injection
- Array injection
- Object injection
Other Injection Types
- Command injection
- XXE (XML External Entity)
- Path traversal
- SSRF
What We Test
OWASP API Security Top 10 (2023)
| Category | What We Check |
|---|---|
| API1 - BOLA | Object-level authorization bypass |
| API2 - Broken Authentication | JWT issues, session problems |
| API3 - Object Property Authorization | Excessive data exposure |
| API4 - Unrestricted Resource Consumption | Rate limiting, resource quotas |
| API5 - Broken Function Authorization | Missing admin/privilege checks |
| API6 - Server Side Request Forgery | SSRF vulnerabilities |
| API7 - Security Misconfiguration | CORS, headers, debug modes |
| API8 - Lack of Protection | Missing bot protection |
| API9 - Improper Asset Management | Deprecated endpoints, versioning |
| API10 - Unsafe API Consumption | Third-party API trust issues |
Additional Testing
- Mass assignment vulnerabilities
- GraphQL-specific issues (if applicable)
- Rate limiting effectiveness
- Error handling information leaks
Combined Testing
Most modern applications have both web and API surfaces that share users, data, and business logic. When you configure both surfaces, both are folded into a single asset map:
- One graph, one report — Web pages and API endpoints are nodes on the same map, and the auditor reasons across both at once
- Cross-surface issues — Vulnerabilities that span both surfaces are identified and linked (e.g., an API endpoint with missing auth that the web app relies on)
- Complete coverage — No gaps between what the frontend exposes and what the backend accepts
Best Practices
Provide Complete OpenAPI Specs
Include all endpoints, even internal ones you want tested:
- Document all parameters and types
- Include authentication requirements
- Describe response schemas
Use Realistic Test Credentials
Provide credentials at different privilege levels:
- Standard user account
- Admin account (if testing admin endpoints)
- Multiple users (for BOLA testing)
Next Steps
Last updated: June 14, 2026