API Penetration Testing

1.1 Documentation Gathering

• Specs: Obtain swagger.json (OpenAPI), WSDL (SOAP), or Schema (GraphQL).
• Postman Collections: Request valid request examples for positive testing.
• Business Logic Map: Understand high-value flows (e.g., "Buy Ticket," "Transfer Funds") to target for Business Flow Logic attacks.

1.2 Scope Definition

• Endpoints & Versions: List all versions (e.g., /v1, /v2, /mobile).
• User Roles: Define distinct roles for testing (e.g., User A, User B, Admin) to test vertical and horizontal privilege escalation.

2.1 Passive Discovery

• OSINT: “Github dorking” for API keys and leaked specs.
• Traffic Analysis: Proxy mobile app/web traffic through Burp Suite to identify undocumented "shadow" API endpoints (API9: Improper Inventory Management).

2.2 Active Discovery

• Fuzzing: Use Kiterunner or FFUF to find hidden paths (/admin, /internal, /actuator).
• Method Verification: Test HTTP verbs on endpoints (e.g., if GET /users exists, test DELETE /users).

3.1 Authorization Testing (API1 & API5)

API1: Broken Object Level Authorization (BOLA):

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object level authorization checks should be considered in every function that accesses a data source using an ID from the user.

• Test: Can User A access User B's resource ID? (e.g., GET /invoices/1001 → GET /invoices/1002).

API5: Broken Function Level Authorization (BFLA):

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.

• Test: Can a regular user access administrative functions? (e.g., POST /api/users/delete or changing method from GET to DELETE).

3.2 Authentication Testing (API2)

API2: Broken Authentication:

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user's identities temporarily or permanently. Compromising a system’s ability to identify the client/user, compromises API security overall.

• Tokens: Check for weak JWT signing secrets, "None" algorithm, or lack of expiration.
• Mechanisms: Test for weak password recovery, lack of brute-force protection on login, or credential stuffing susceptibilit

3.3 Data Exposure & Manipulation (API3)

API3: Broken Object Property Level Authorization (BOPLA):

This category combines API3:2019 Excessive Data Exposure and API6:2019 - Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.

• Concept: This merges the 2019 "Mass Assignment" and "Excessive Data Exposure" categories. It focuses on the user's ability to access or modify specific properties of an object they shouldn't.
• Excessive Exposure Test: Inspect JSON responses. Does GET /user/profile return sensitive backend fields like is_admin, password_hash, or pii_ssn that the UI hides?
• Mass Assignment Test: Try to inject unauthorized fields in a POST or PUT request.
• Payload: {"username": "test", "role": "admin", "balance": 999999}.

3.4 Resource & Business Logic (API4 & API6)

API4: Unrestricted Resource Consumption:

• Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage. Other resources such as emails/SMS/phone calls or biometrics validation are made available by service providers via API integrations, and paid for per request. Successful attacks can lead to Denial of Service or an increase of operational costs.
• Test: Send huge payloads, deeply nested GraphQL queries, or thousands of requests (DoS) to exhaust CPU, memory, or storage.
• Check: Are there timeouts? Are there strict rate limits?

API6: Unrestricted Access to Sensitive Business Flows:

• APIs vulnerable to this risk expose a business flow - such as buying a ticket, or posting a comment - without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn't necessarily come from implementation bugs.
• Concept: Automation abusing legitimate logic.
• Test: Script a bot to buy all tickets (Scalping) or create 1000 spam accounts. The API technically "works," but the business flow is damaged.

3.5. Injection & Server Risks (API7 & API8)

API7: Server Side Request Forgery (SSRF):

• Server-Side Request Forgery (SSRF) flaws can occur when an API is fetching a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN.
• Test: If an API endpoint accepts a URL (e.g., "Upload via URL" or "Webhook"), try to force the server to connect to internal resources (e.g., http://169.254.169.254/latest/meta-data on cloud, or http://localhost:8080).

API8: Security Misconfiguration:

• APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don't follow security best practices when it comes to configuration, opening the door for different types of attacks.
• Test: Check for verbose error messages (stack traces), CORS misconfigurations (wildcard * origins), or unpatched servers.

3.6. Integrations & Inventory (API9 & API10)

API9: Improper Inventory Management:

• APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. A proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.
• Test: Look for Zombie APIs (deprecated versions like /v1 still active) or Shadow APIs (undocumented endpoints).

API10: Unsafe Consumption of APIs:

• Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. In order to compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.
• Concept: The target API trusts data from another 3rd party API blindly.
• Test: If the target integrates with a payment provider or external service, can you spoof the response from that service to trick the API?

During the exploitation phases, vulnerabilities will be linked together, or "chained," to achieve the maximum possible impact.

• BOLA + BFLA: Use a BOLA vulnerability to find an Admin's User ID, then use BFLA to delete that ID.
• BOPLA (Mass Assignment): Register a user and inject "is_admin": true to gain administrative privileges immediately.
• SSRF to Keys: Use API7 (SSRF) to hit the metadata service, steal AWS keys, and then use those keys to query the database directly.

• Executive Summary: A high-level, non-technical summary for management, focusing on business risk, key findings, and the overall security posture.
• Technical Report: A detailed report for developers and IT teams.
• Attack Narrative: A step-by-step walkthrough of the most significant exploit chains.
• Vulnerability Details: For each finding, provide:
• Description: A clear explanation of the vulnerability (e.g., "OWASP A03: Injection").
• Affected URLs/Parameters: The exact location of the flaw.
• Evidence: Screenshots, HTTP requests/responses, and code snippets.
• Impact: The potential business impact.
• Risk Rating: A score (e.g., Critical, High, Medium, Low) to prioritize.
• Remediation: Provide clear, prioritized, and step-by-step instructions for fixing each vulnerability, including code examples where possible

Remediation and Re-testing

• Present the findings to the client in a debrief meeting.
• After the client has implemented the fixes, perform a targeted re-test to validate that the vulnerabilities have been successfully remediated.