๐ OWASP API Security Training
Understanding API Documentation & Security Considerations
โ ๏ธ Critical Reality Check: API documentation is created by developers, which means it can
be hidden, obfuscated, outdated, incomplete, or simply not work as expected. Always approach documentation
with skepticism and be prepared to test everything independently.
๐ Introduction to API Documentation
API documentation serves as the blueprint for interacting with Application Programming Interfaces. However,
security professionals must understand that documentation should be treated with caution. Since developers
create this documentation, it may contain vulnerabilities, inconsistencies, or intentional obfuscation that
can impact security testing.
Key Takeaway: Never fully trust API documentation at face value. Always verify, test, and
explore beyond what's documented.
โ
Components of Good API Documentation
Essential Elements:
| Component |
Description |
Security Relevance |
| Endpoints & Methods |
URL paths and HTTP methods (GET, POST, PUT, DELETE, etc.) |
Hidden endpoints may exist beyond documentation |
| Parameters |
Required vs. optional parameters, data types |
Undocumented parameters can reveal vulnerabilities |
| Request/Response Examples |
Sample data structures and formats |
May expose sensitive data structures |
| Status & Error Codes |
HTTP status codes and custom error messages |
Error messages can leak system information |
| Rate Limitations |
API throttling and usage limits |
Important for DoS testing and abuse prevention |
๐ ๏ธ Major API Documentation Tools & Formats
1. OpenAPI Specification (Swagger)
Overview: OpenAPI Specifications use Swagger for interactive API documentation. This
standardized format allows for auto-generation of documentation and easy import into testing tools like
Postman.
Swagger/OpenAPI Benefits:
- Standardized Format: Define once, generate automatically
- Interactive Testing: Try endpoints directly from documentation
- Tool Integration: Import into Postman, Burp Suite, and other security tools
- Version Control: Easy to track API changes over time
๐ด Security Consideration: Swagger documentation can expose entire API structure,
authentication methods, and data models to attackers. Organizations often mistakenly leave Swagger UI
publicly accessible.
curl -X GET "https://api.example.com/swagger.json" -H "accept: application/json"
curl -X GET "https://api.example.com/v2/api-docs" -H "accept: application/json"
curl -X GET "https://api.example.com/openapi.json" -H "accept: application/json"
2. Postman Collections
Overview: Postman Collections are a form of API documentation that contain
pre-configured requests, environments, and test scripts. When found on GitHub or shared publicly, they
provide invaluable insight into API structure.
Using Postman Collections for Security Testing:
- Search GitHub for "
site:github.com api.target.com postman"
- Look for
.postman_collection.json files
- Import collections into Postman or convert to other formats
- Analyze environment variables for sensitive data
grep -r "postman_collection" /path/to/repository/
find . -name "*.postman_collection.json" -type f
๐ด Critical Security Risk: Postman collections frequently contain hard-coded credentials,
API keys, tokens, and internal endpoints. Developers often forget these secrets are embedded in shared
collections.
Example of Hard-coded Credentials in Postman:
{
"variable": [
{
"key": "api_key",
"value": "sk_live_51Hxxx...", โ EXPOSED SECRET
"type": "string"
},
{
"key": "admin_token",
"value": "Bearer eyJhbGc...", โ EXPOSED TOKEN
"type": "string"
}
]
}
3. API Blueprint
Overview: API Blueprint uses markdown-based syntax for documentation. It's an
alternative to OpenAPI/Swagger with a more human-readable format.
๐ก Resource: Learn more about API Blueprint and compare it with OpenAPI at
https://apiblueprint.org/
๐ Authentication & Authorization Documentation
Why Clear Authentication Documentation Matters:
Different APIs require different authentication mechanisms. Proper documentation should clearly specify how
to authenticate, but this is often poorly documented or completely missing.
Common API Authentication Methods
API Keys
โ
Bearer Tokens
โ
OAuth 2.0
โ
JWT
โ
Basic Auth
| Authentication Type |
Common Implementation |
Testing Command Example |
| API Key |
Header or Query Parameter |
X-API-Key: your_api_key_here |
| Bearer Token |
Authorization Header |
Authorization: Bearer token_value |
| OAuth 2.0 |
Token Exchange Flow |
Authorization: Bearer oauth_token |
| JWT |
Signed Token in Header |
Authorization: Bearer eyJhbGci... |
| Basic Auth |
Base64 Encoded Credentials |
Authorization: Basic dXNlcjpwYXNz |
Testing Authentication Commands:
curl -X GET "https://api.example.com/user/profile" -H "X-API-Key: your_api_key_here"
curl -X GET "https://api.example.com/user/profile" -H "Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
curl -X GET "https://api.example.com/user/profile" -H "Authorization: Basic $(echo -n
'username:password' | base64)"
curl -X POST "https://api.example.com/oauth/token" -d
"grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET"
โ ๏ธ Common Issue: Even if documentation states authentication is required, always test
endpoints without authentication. Developers often neglect to enforce authentication on all endpoints,
especially older API versions.
๐ API Versioning & Documentation
Understanding Version Management:
APIs often maintain multiple versions simultaneously. Each version may have its own documentation, security
controls, and vulnerabilities. Older versions frequently contain security flaws that have been patched in
newer versions.
API Version Discovery Process
Find Current Version
โ
Test Older Versions
โ
Test Beta/Dev Versions
โ
Compare Security Controls
Version Discovery Commands:
curl -X GET "https://api.example.com/v1/users" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/v2/users" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/v3/users" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/beta/users" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/dev/users" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/internal/users" -H "Authorization: Bearer TOKEN"
๐ก Pro Tip: Always test multiple API versions. Older versions often lack security controls
that were added to newer versions. Documentation may only cover the latest version, leaving older versions
as hidden attack surfaces.
๐งช Interactive Documentation & Testing
Benefits of Interactive Documentation:
- Web Interface Testing: Try endpoints directly through Swagger UI or similar tools
- Quick Prototyping: Understand API behavior without writing code
- curl Command Generation: Convert interactive requests to curl commands
- Code Snippet Export: Generate Python, JavaScript, or other language examples
โ ๏ธ Don't Get Too Comfortable: Interactive documentation is convenient, but true security
testing requires scripting and automation. Convert your tests to scripts for repeatable, thorough testing.
Converting Swagger to curl Commands:
From Swagger UI to curl:
Most Swagger interfaces provide a "Try it out" button that generates curl commands. Always copy and adapt
these for your own scripts.
curl -X POST "https://api.example.com/v1/users" -H "accept: application/json" -H
"Content-Type: application/json" -d '{"username":"testuser","email":"
[email protected]"}'
Converting curl to Python Script:
Python Requests Example:
import requests
url = "https://api.example.com/v1/users"
headers = {
"accept": "application/json",
"Content-Type": "application/json",
"Authorization": "Bearer YOUR_TOKEN"
}
data = {
"username": "testuser",
"email": "[email protected]"
}
response = requests.post(url, headers=headers, json=data)
print(f"Status Code: {response.status_code}")
print(f"Response: {response.json()}")
๐ฏ Beyond Documentation: Discovery Techniques
Endpoint Discovery:
Documentation rarely covers all endpoints. Use these techniques to discover hidden or undocumented
endpoints:
ffuf -u https://api.example.com/FUZZ -w /path/to/api-endpoints.txt -mc
200,201,301,302,401,403
wfuzz -c -z file,/path/to/wordlist.txt --hc 404 https://api.example.com/FUZZ
gobuster dir -u https://api.example.com -w /path/to/api-wordlist.txt -x json,xml
Parameter Discovery:
arjun -u https://api.example.com/v1/users -m GET
paramspider -d example.com
curl -X GET "https://api.example.com/v1/users?debug=true" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/v1/users?admin=true" -H "Authorization: Bearer TOKEN"
curl -X GET "https://api.example.com/v1/users?internal=true" -H "Authorization: Bearer
TOKEN"
Common Hidden Parameters to Test:
| Parameter |
Purpose |
Example Value |
debug |
Enable debug mode |
true, 1, yes |
admin |
Privilege escalation |
true, 1 |
internal |
Internal API access |
true, 1 |
test |
Test mode |
true, 1 |
verbose |
Detailed output |
true, 1 |
format |
Response format |
json, xml, debug |
โ ๏ธ Common Pitfalls in API Documentation
1. Outdated Information
Documentation often lags behind actual API implementation. Endpoints, parameters, and authentication
methods may have changed without documentation updates.
2. Unclear Authentication Instructions
Authentication flows can be complex, especially with OAuth 2.0 or custom token systems. Documentation may
assume knowledge or skip crucial steps.
Solution: Look for authentication examples on GitHub, Stack Overflow, or in Postman
collections from other users.
3. Missing Edge Cases & Error Handling
Documentation typically shows the "happy path" but rarely covers error scenarios, rate limiting behavior,
or input validation rules.
Testing Edge Cases:
curl -X POST "https://api.example.com/v1/users" -H "Content-Type: application/json" -d
'{"username":"A"}' # Too short
curl -X POST "https://api.example.com/v1/users" -H "Content-Type: application/json" -d
'{"username":"' + 'A'*10000 + '"}' # Too long
curl -X POST "https://api.example.com/v1/users" -H "Content-Type: application/json" -d
'{"username":null}' # Null value
curl -X POST "https://api.example.com/v1/users" -H "Content-Type: application/json" -d
'{"username":{"nested":"object"}}' # Wrong type
4. Business Logic Not Documented
Business logic vulnerabilities arise from application-specific workflows that are never documented. These
require understanding the application's purpose and testing accordingly.
๐ก๏ธ The Role of Documentation in Security
Documentation Security Paradox
For Developers:
- Good documentation improves development efficiency
- Helps onboard new team members
- Reduces support burden
For Attackers:
- Reveals complete API surface area
- Exposes authentication mechanisms
- Shows data structures and relationships
- Identifies potential weak points
Security Best Practices for Documentation:
| Best Practice |
Implementation |
Reality |
| Restrict Access |
Internal network only, VPN required |
Often publicly accessible |
| Authentication Required |
Require login to view docs |
Frequently unauthenticated |
| Separate Environments |
Different docs for prod vs. dev |
Same docs for all environments |
| Remove Sensitive Info |
No internal endpoints or secrets |
Contains internal details |
| Regular Audits |
Review what's exposed |
Set and forget |
๐ก The Harsh Reality: Despite best practices, developers often prioritize functionality
over security. This means documentation is frequently left publicly accessible at predictable endpoints like
/docs, /api-docs, /swagger, or /v2/api-docs.
Common Documentation Exposure Points:
curl -X GET "https://api.example.com/docs" -H "accept: text/html"
curl -X GET "https://api.example.com/api-docs" -H "accept: application/json"
curl -X GET "https://api.example.com/swagger" -H "accept: text/html"
curl -X GET "https://api.example.com/swagger.json" -H "accept: application/json"
curl -X GET "https://api.example.com/v2/api-docs" -H "accept: application/json"
curl -X GET "https://api.example.com/openapi.json" -H "accept: application/json"
curl -X GET "https://api.example.com/redoc" -H "accept: text/html"
curl -X GET "https://api.example.com/graphql" -H "accept: text/html"
๐ Practical Security Testing Workflow
Complete API Security Testing Process
Step 1: Document Discovery
Find Swagger, Postman collections, API Blueprint
โ
Step 2: Analyze Documentation
Identify endpoints, auth methods, parameters
โ
Step 3: Test Documented Endpoints
Verify accuracy, test edge cases
โ
Step 4: Discover Hidden Endpoints
Fuzzing, parameter discovery, version testing
โ
Step 5: Authentication Bypass Testing
Test without auth, test with different auth levels
โ
Step 6: Business Logic Testing
Workflow abuse, privilege escalation
โ
Step 7: Automate & Script
Convert findings to repeatable tests
๐ Key Takeaways
- โ Trust but Verify: Always test documentation claims independently
- โ Expect Incompleteness: Documentation is rarely complete or current
- โ Search for Secrets: Check Postman collections and code repositories for
hard-coded credentials
- โ Test All Versions: Older API versions often have weaker security
- โ Go Beyond Docs: Fuzz for hidden endpoints and parameters
- โ Automate Testing: Convert interactive tests to scripts
- โ Test Edge Cases: Business logic flaws aren't in documentation
- โ Assume Exposure: Check common documentation paths on every target
๐ Summary
API documentation is a double-edged sword in security testing. While it provides valuable information about
API structure and functionality, it should never be your sole source of truth. The most critical
vulnerabilities often exist in undocumented endpoints, forgotten API versions, or poorly secured
documentation endpoints themselves.
Remember: Developers prioritize functionality over security, and documentation practices reflect this
reality. Your job as a security professional is to find what's hidden, test what's assumed to be secure, and
never trust that documentation tells the complete story.