🛡️ OWASP API Security Testing Guide

Professional Penetration Testing and Reporting Standards

📋 Table of Contents

  1. Introduction to API Security Testing
  2. Report Structure Requirements
  3. Executive Summary Guidelines
  4. Testing Methodology
  5. Documenting Findings
  6. Recommendations
  7. Practical Examples
  8. Testing Tools and Commands
  9. CVSS Scoring Guide

🎯 Introduction to API Security Testing

API security testing is a critical component of modern application security assessments. With the increasing reliance on APIs for interconnecting services, identifying and mitigating vulnerabilities in these interfaces has become paramount. This guide focuses on creating professional penetration testing reports that meet industry standards.

Key Objective: Your report should be understandable, readable, and correct. Avoid blatant mistakes such as mislabeling vulnerabilities (e.g., confusing IDOR with CSRF). Quality matters, and incomplete or incorrect reports may result in failure.

📄 Report Structure Requirements

A comprehensive penetration testing report must contain specific elements to be considered complete and professional. Below is the essential structure your report must follow:

Essential Report Components

  • Executive Summary - High-level overview for management
  • Methodology - Detailed testing approach and tools used
  • Findings - Complete vulnerability documentation
  • Recommendations - Remediation guidance (general and specific)
  • CVSS Scoring - Severity ratings for all findings
  • Priority Classification - High, Medium, Low categorization
  • Appendices - Supporting materials (Postman collections, scripts, etc.)

Report Structure Flow Diagram

Executive Summary
→
Methodology
→
Findings
→
Recommendations
→
Appendices

📊 Executive Summary Guidelines

The executive summary should be placed at the top of your report. It serves as a high-level overview intended for stakeholders who may not have technical expertise but need to understand the security posture of the API.

What to Include

  • High-Level Overview: Brief description of the testing engagement scope and objectives
  • Testing Process Summary: General approach taken during the assessment
  • Key Findings: Summary of the most critical vulnerabilities discovered
  • Potential Impact: Business and security implications of the findings
  • Risk Summary Table: Quantified breakdown of vulnerability severity

Example: Risk Summary Table

Severity Count Examples
Critical 2 SQL Injection, Broken Authentication
High 5 IDOR, Broken Access Control, XXE
Medium 8 CSRF, Security Misconfiguration
Low 3 Information Disclosure, Missing Headers

🔬 Testing Methodology

The methodology section describes how you conducted your testing. While it may overlap with your test plan, it's important to document the actual approach taken, including any deviations from the original plan.

Important: Document any deviations from your master plan. If you changed your testing approach, tools, or scope during the engagement, these changes MUST be mentioned in this section.

🔍 Reconnaissance

Gathering information about the API endpoints, authentication mechanisms, and data structures.

🎯 Vulnerability Scanning

Automated and manual scanning for common vulnerabilities using specialized tools.

🛠️ Exploitation

Attempting to exploit discovered vulnerabilities to determine actual risk and impact.

📝 Documentation

Recording all findings with evidence, steps to reproduce, and impact assessment.

Key Elements to Document

  • Testing Scope: Which APIs, endpoints, and functionalities were tested
  • Tools Used: Burp Suite, Postman, curl, custom scripts, etc.
  • Testing Approach: Black-box, grey-box, or white-box testing
  • Time Period: Duration of the testing engagement
  • Limitations: Any constraints or areas not tested
  • Deviations: Changes from the original test plan

🔎 Documenting Findings

Each vulnerability finding must be thoroughly documented with sufficient detail to allow developers to understand and reproduce the issue. The following structure ensures comprehensive documentation.

Required Components for Each Finding

1. Introduction/Description

Provide a clear explanation of the vulnerability, what it is, and why it matters.

2. Prerequisites

List any requirements needed to execute the exploit scenario (e.g., valid credentials, specific user role, network access).

3. Steps to Reproduce

Detailed step-by-step instructions that allow someone to replicate the vulnerability. Each step should be clear and actionable.

4. Actual Result

What actually happened when you executed the steps (include screenshots, API responses, error messages).

5. Expected Result

What should have happened in a secure implementation (e.g., "Access should be denied", "Input should be sanitized").

6. Test Evidence

Screenshots, request/response data, logs, or any other proof of the vulnerability.

7. Impact Assessment

Explain the potential consequences if this vulnerability were exploited by an attacker.

8. CVSS Score

Calculated severity score using the Common Vulnerability Scoring System.

9. Recommendation

Specific guidance on how to fix this particular vulnerability.

Example Finding: Insecure Direct Object Reference (IDOR)

Description

The API endpoint /api/users/{userId}/profile allows authenticated users to access any user's profile information by simply changing the userId parameter. No authorization checks are performed to verify if the requesting user has permission to view the requested profile.

Prerequisites

  • Valid user account and authentication token
  • Knowledge of the API endpoint structure

Steps to Reproduce

curl -X GET "https://api.example.com/api/users/123/profile" -H "Authorization: Bearer YOUR_TOKEN"

1. Authenticate as a regular user (user ID 456)

curl -X POST "https://api.example.com/api/auth/login" -H "Content-Type: application/json" -d '{"username":"testuser","password":"password123"}'

2. Note your authentication token from the response

3. Attempt to access another user's profile (user ID 123)

curl -X GET "https://api.example.com/api/users/123/profile" -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

4. Observe the response contains full profile details of user 123

Actual Result

The API returns the complete profile information of user 123, including sensitive data such as email address, phone number, and account settings, despite the request originating from user 456.

Expected Result

The API should return an HTTP 403 Forbidden error with a message indicating insufficient permissions, or should only return the requesting user's own profile data.

Impact

An attacker can enumerate and access all user profiles in the system, potentially exposing personally identifiable information (PII), account details, and other sensitive data. This could lead to privacy violations, identity theft, and compliance issues (GDPR, CCPA).

CVSS v3.1 Score

7.5 (High)

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Recommendation

Implement proper authorization checks in the API endpoint to verify that the authenticated user has permission to access the requested resource. Use an authorization framework that enforces access control policies based on user roles and ownership.

💡 Recommendations

The recommendations section should provide both individual remediation guidance for specific vulnerabilities and general security improvements that address multiple findings or systemic issues.

Types of Recommendations

Individual Recommendations

Specific fixes for individual vulnerabilities. Each finding should have its own targeted recommendation.

General Recommendations

Overarching security improvements that address multiple related vulnerabilities or prevent entire classes of attacks.

Example: General Recommendation for Multiple IDOR Findings

Finding: During testing, 5 separate instances of Insecure Direct Object Reference (IDOR) vulnerabilities were discovered across different API endpoints.

General Recommendation: Conduct a comprehensive application-wide audit to identify and remediate all potential IDOR vulnerabilities. Implement a centralized authorization framework that enforces access control checks before processing any resource request. Consider implementing the following measures:

  • Use indirect reference maps (UUIDs instead of sequential IDs)
  • Implement attribute-based access control (ABAC) or role-based access control (RBAC)
  • Create automated tests to verify authorization checks on all API endpoints
  • Establish secure coding guidelines that require authorization validation for every data access operation
Priority Classification: All recommendations should be categorized as High, Medium, or Low priority based on the severity of the vulnerability and the ease of exploitation. Critical and High severity findings should always be addressed first.

🧪 Practical Examples

Example 1: SQL Injection in API Parameter

Vulnerability Description

The /api/search endpoint accepts a query parameter that is directly concatenated into a SQL statement without proper sanitization or parameterization.

Steps to Reproduce

1. Send a normal search request

curl -X GET "https://api.example.com/api/search?query=test"

2. Test for SQL injection by appending a single quote

curl -X GET "https://api.example.com/api/search?query=test'"

3. Observe SQL error in the response, confirming vulnerability

4. Exploit using UNION-based injection to extract data

curl -X GET "https://api.example.com/api/search?query=test' UNION SELECT username,password,email FROM users--"

Impact

Critical: Complete database compromise, including unauthorized data access, modification, and potential deletion. Attacker could extract all user credentials, personal information, and sensitive business data.

Recommendation

  • Use parameterized queries or prepared statements for all database operations
  • Implement input validation and sanitization
  • Apply principle of least privilege to database accounts
  • Enable database logging and monitoring for suspicious queries

Example 2: Broken Authentication (JWT Token Issues)

Vulnerability Description

The API uses JWT tokens for authentication, but the tokens are signed with a weak secret key that can be brute-forced. Additionally, tokens do not expire and lack proper validation.

Steps to Reproduce

1. Obtain a valid JWT token through legitimate authentication

curl -X POST "https://api.example.com/api/login" -H "Content-Type: application/json" -d '{"username":"user","password":"pass"}'

2. Decode the JWT token to examine its structure

echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VySWQiOjEyMywicm9sZSI6InVzZXIifQ.signature" | base64 -d

3. Use a tool like jwt_tool to crack the secret key

python3 jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... -C -d /usr/share/wordlists/rockyou.txt

4. Create a forged token with elevated privileges

python3 jwt_tool.py eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... -T -p "cracked_secret" -I -pc "role" -pv "admin"

5. Use the forged token to access admin-only endpoints

curl -X GET "https://api.example.com/api/admin/users" -H "Authorization: Bearer FORGED_TOKEN"

Impact

Critical: Complete authentication bypass allowing attackers to impersonate any user, including administrators. This leads to unauthorized access to all system resources and functions.

Recommendation

  • Use a cryptographically strong, randomly generated secret key (minimum 256 bits)
  • Implement token expiration with reasonable timeframes (e.g., 15 minutes for access tokens)
  • Use refresh tokens with longer expiration for session persistence
  • Store secret keys securely using environment variables or secret management systems
  • Implement token revocation mechanisms
  • Consider using asymmetric signing (RS256) instead of symmetric (HS256)

Example 3: Mass Assignment Vulnerability

Vulnerability Description

The API's user update endpoint accepts arbitrary JSON parameters and directly updates the database without filtering allowed fields. This allows attackers to modify protected attributes.

Steps to Reproduce

1. Authenticate as a regular user

curl -X POST "https://api.example.com/api/login" -H "Content-Type: application/json" -d '{"username":"regularuser","password":"password"}'

2. Update user profile with legitimate fields

curl -X PUT "https://api.example.com/api/users/profile" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d '{"name":"John Doe","email":"[email protected]"}'

3. Attempt to modify protected fields (role, isAdmin, accountBalance)

curl -X PUT "https://api.example.com/api/users/profile" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json" -d '{"name":"John Doe","role":"admin","isAdmin":true,"accountBalance":1000000}'

4. Verify the unauthorized modifications were applied

curl -X GET "https://api.example.com/api/users/profile" -H "Authorization: Bearer TOKEN"

Impact

High: Privilege escalation, unauthorized financial transactions, data integrity compromise. Users can elevate their own privileges or modify critical system attributes.

Recommendation

  • Implement a whitelist of allowed fields for each endpoint
  • Use Data Transfer Objects (DTOs) to explicitly define acceptable parameters
  • Separate sensitive fields into admin-only endpoints with additional authorization
  • Apply input validation and sanitization on all user-provided data

🛠️ Testing Tools and Commands

Essential API Testing Tools

Tool Purpose Key Features
Burp Suite Web application security testing platform Proxy, Scanner, Repeater, Intruder
Postman API development and testing Request builder, Collections, Environment variables
OWASP ZAP Open-source web application scanner Active/Passive scanning, Fuzzing
curl Command-line HTTP client Flexible request manipulation
JWT_Tool JWT token testing and exploitation Token cracking, Forgery, Analysis
SQLMap Automated SQL injection testing Database enumeration, Data extraction

Common Testing Commands

Basic API Request with curl

curl -X GET "https://api.example.com/endpoint" -H "Authorization: Bearer TOKEN" -H "Content-Type: application/json"

POST Request with JSON Body

curl -X POST "https://api.example.com/api/users" -H "Content-Type: application/json" -d '{"username":"testuser","email":"[email protected]"}'

Testing with Custom Headers

curl -X GET "https://api.example.com/api/data" -H "X-Custom-Header: value" -H "User-Agent: Mozilla/5.0" -v

Saving Response to File

curl -X GET "https://api.example.com/api/export" -H "Authorization: Bearer TOKEN" -o response.json

Following Redirects

curl -L -X GET "https://api.example.com/redirect"

Testing with Burp Suite Proxy

curl -x http://127.0.0.1:8080 -k "https://api.example.com/endpoint"

SQL Injection Testing with SQLMap

sqlmap -u "https://api.example.com/api/search?query=test" --batch --level=5 --risk=3

Decoding JWT Token

echo "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.payload.signature" | cut -d. -f2 | base64 -d | jq

Nikto Web Server Scanning

nikto -h https://api.example.com -ssl

Nmap API Port Scanning

nmap -sV -p 80,443,8080,8443 api.example.com

📈 CVSS Scoring Guide

Understanding CVSS v3.1

The Common Vulnerability Scoring System (CVSS) provides a standardized method for rating the severity of security vulnerabilities. CVSS scores range from 0.0 to 10.0, with higher scores indicating more severe vulnerabilities.

Severity Ratings

Rating Score Range Description
Critical 9.0 - 10.0 Vulnerabilities that can be easily exploited remotely with severe impact
High 7.0 - 8.9 Serious vulnerabilities with significant impact or easier exploitation
Medium 4.0 - 6.9 Moderate vulnerabilities that require specific conditions or have limited impact
Low 0.1 - 3.9 Minor vulnerabilities with minimal impact or difficult exploitation

CVSS v3.1 Metrics

  • Attack Vector (AV): Network (N), Adjacent (A), Local (L), Physical (P)
  • Attack Complexity (AC): Low (L), High (H)
  • Privileges Required (PR): None (N), Low (L), High (H)
  • User Interaction (UI): None (N), Required (R)
  • Scope (S): Unchanged (U), Changed (C)
  • Confidentiality Impact (C): None (N), Low (L), High (H)
  • Integrity Impact (I): None (N), Low (L), High (H)
  • Availability Impact (A): None (N), Low (L), High (H)

Example CVSS Calculations

SQL Injection

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Score: 10.0 (Critical)

Reasoning: Network accessible, low complexity, no privileges required, no user interaction, scope change, high impact on all CIA triad elements.

IDOR (Insecure Direct Object Reference)

Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

Score: 7.5 (High)

Reasoning: Network accessible, low complexity, low privileges required (authenticated user), no user interaction, high confidentiality impact.

CSRF (Cross-Site Request Forgery)

Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N

Score: 6.5 (Medium)

Reasoning: Network accessible, low complexity, no privileges required, user interaction required, high integrity impact.

Vulnerability Prioritization Matrix

Priority Criteria Action Timeline
P1 - Critical CVSS 9.0-10.0, Actively exploited, High business impact Immediate (24-48 hours)
P2 - High CVSS 7.0-8.9, Significant risk, Data exposure 1-2 weeks
P3 - Medium CVSS 4.0-6.9, Moderate risk, Requires conditions 1-3 months
P4 - Low CVSS 0.1-3.9, Minimal risk, Best practice Next maintenance cycle

📑 Appendices

What to Include in Appendices

The appendices section should contain all supporting materials that provide additional context or evidence for your findings but would make the main report too lengthy or technical.

  • Postman Collections: Exported API request collections used during testing
  • Burp Suite Project Files: Saved session data and scan results
  • Custom Scripts: Any automation scripts or tools created for testing
  • Raw Response Data: Full API responses for critical findings
  • Network Traffic Captures: Relevant packet captures (PCAP files)
  • Configuration Files: Tool configurations used during testing
  • Wordlists/Payloads: Custom wordlists or payload collections used
  • Reference Documentation: Links to relevant CVEs, CWEs, or security advisories

📌 Key Takeaways

  • Your report must be understandable, readable, and accurate
  • Avoid blatant mistakes such as mislabeling vulnerabilities
  • Include all required sections: Executive Summary, Methodology, Findings, Recommendations, Appendices
  • Document any deviations from your original test plan
  • Provide detailed steps to reproduce for every finding
  • Include both actual and expected results for each vulnerability
  • Assign CVSS scores to all findings
  • Provide both specific and general recommendations
  • Use the provided pen testing report template as your standard
  • Support your findings with screenshots and evidence

⚠️ Quality Standards

Your report will be evaluated on:

  • Completeness of all required sections
  • Accuracy of vulnerability identification and classification
  • Quality of documentation and reproducibility
  • Professional presentation and organization
  • Correctness of CVSS scoring and severity ratings
  • Usefulness and specificity of recommendations

Incomplete or incorrect reports may result in failure. Ensure your work meets the standards outlined in the provided pen testing report template.

🔗 Additional Resources