conducting-api-security-testing

Conducts security testing of REST, GraphQL, and gRPC APIs to identify vulnerabilities in authentication, authorization, rate limiting, input validation, and business logic. The tester uses the OWASP API Security Top 10 as the testing framework, combining Burp Suite interception with Postman collections and custom scripts to test endpoint security at every privilege level. Activates for requests involving API security testing, REST API pentest, GraphQL security assessment, or API vulnerability testing.

Jump to install

Repository: autohandai/community-skills
Last source activity: March 16, 2026 at 00:59
Detected SKILL.md language: English
Stars: 10
Forks: 3

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

name	conducting-api-security-testing
description	Conducts security testing of REST, GraphQL, and gRPC APIs to identify vulnerabilities in authentication, authorization, rate limiting, input validation, and business logic. The tester uses the OWASP API Security Top 10 as the testing framework, combining Burp Suite interception with Postman collections and custom scripts to test endpoint security at every privilege level. Activates for requests involving API security testing, REST API pentest, GraphQL security assessment, or API vulnerability testing.
domain	cybersecurity
subdomain	penetration-testing
tags	["API-security","OWASP-API-Top10","REST","GraphQL","authorization-testing"]
version	1.0.0
author	mahipal
license	Apache-2.0

Conducting API Security Testing

When to Use

Testing API endpoints for authorization flaws, injection vulnerabilities, and business logic bypasses
Assessing the security of microservices architecture where APIs are the primary communication method
Validating that API gateway protections (rate limiting, authentication, input validation) are properly enforced
Testing third-party API integrations for data exposure and insecure configurations
Evaluating GraphQL APIs for introspection disclosure, query complexity attacks, and authorization bypasses

Do not use against APIs without written authorization, for load testing or denial-of-service testing unless explicitly scoped, or for testing production APIs that process real financial transactions without safeguards.

Prerequisites

API documentation (OpenAPI/Swagger, GraphQL schema, Postman collection) or application access to reverse-engineer the API
Burp Suite Professional configured to intercept API traffic with JSON/XML content type handling
Postman or Insomnia for organizing and replaying API requests across different authentication contexts
Valid API tokens or credentials at multiple privilege levels (unauthenticated, standard user, admin)
Target API base URL and version information

Workflow

Step 1: API Discovery and Documentation

Map the complete API attack surface:

Import API documentation: Load OpenAPI/Swagger specs into Postman or Burp Suite to catalog all endpoints, methods, parameters, and authentication requirements
Reverse-engineer undocumented APIs: Proxy the mobile app or web frontend through Burp Suite and exercise all features to capture API calls. Export the Burp sitemap as the baseline endpoint inventory.
GraphQL introspection: Send an introspection query to discover the full schema:
```
{"query": "{__schema{types{name,fields{name,args{name,type{name}}}}}}"}
```
Endpoint enumeration: Fuzz for hidden API versions (/api/v1/, /api/v2/, /api/internal/), debug endpoints (/api/debug, /api/health, /api/metrics), and administrative endpoints
Document authentication mechanisms: Identify if the API uses API keys, OAuth 2.0 Bearer tokens, JWT, session cookies, or mutual TLS

BOLA (IDOR) testing: For every endpoint that returns user-specific data, replace the object identifier with another user's identifier:
- GET /api/users/123/orders -> GET /api/users/456/orders
- Test with numeric IDs, UUIDs, usernames, and email addresses
- Automate with Burp Autorize extension: configure it with two sessions (attacker and victim) and replay all requests
BFLA testing: Using a low-privilege token, attempt to access administrative endpoints:
- DELETE /api/users/456 (admin-only delete)
- PUT /api/users/456/role (role modification)
- GET /api/admin/dashboard (admin panel data)

Mass assignment: Send additional JSON properties not shown in the documentation:

PUT /api/users/123
{"name": "Test", "role": "admin", "isVerified": true, "balance": 99999}

HTTP method testing: If GET works on an endpoint, try PUT, PATCH, DELETE, and OPTIONS to discover unprotected methods

Term	Definition
BOLA	Broken Object Level Authorization (OWASP API #1); failure to verify that the requesting user is authorized to access a specific object, enabling IDOR attacks
BFLA	Broken Function Level Authorization (OWASP API #5); failure to restrict administrative or privileged API functions from being accessed by lower-privilege users
Mass Assignment	A vulnerability where the API binds client-provided data to internal object properties without filtering, allowing attackers to modify fields they should not have access to
GraphQL Introspection	A built-in GraphQL feature that exposes the complete API schema including all types, fields, and relationships; should be disabled in production
JWT	JSON Web Token; a self-contained token format used for API authentication containing claims signed with a secret or key pair
Rate Limiting	Controls that restrict the number of API requests a client can make within a time window, preventing brute force, enumeration, and abuse

## Finding: Broken Object Level Authorization in Transaction History API

**ID**: API-001
**Severity**: Critical (CVSS 9.1)
**Affected Endpoint**: GET /api/v1/accounts/{accountId}/transactions
**OWASP API Category**: API1:2023 - Broken Object Level Authorization

**Description**:
The transaction history endpoint returns all transactions for the specified
account without verifying that the authenticated user owns the account. Any
authenticated user can view the complete transaction history of any account
by substituting the accountId path parameter.

**Proof of Concept**:
1. Authenticate as User A (account ID: ACC-10045)
2. Request: GET /api/v1/accounts/ACC-10046/transactions
   Authorization: Bearer <User_A_token>
3. Response: 200 OK with User B's full transaction history

**Impact**:
Any authenticated user can view the complete financial transaction history of
all 45,000 customer accounts, including amounts, dates, recipients, and
transaction descriptions.

**Remediation**:
Implement server-side authorization check that verifies the authenticated user
owns the requested account before returning data:
  const account = await Account.findById(accountId);
  if (account.userId !== req.user.id) return res.status(403).json({error: "Forbidden"});