Opening Framing: The API-First World
Modern applications are API-driven. Mobile apps, single-page applications, microservices, and third-party integrations all communicate through APIs. This architectural shift creates a vast new attack surface.
APIs differ from traditional web applications. They're designed for machine consumption, often lack the visual context that helps identify functionality, and may expose more direct access to business logic than web interfaces.
This week covers REST API testing, GraphQL security, API authentication mechanisms, and the OWASP API Security Top 10— the unique vulnerabilities that affect programmatic interfaces.
Key insight: APIs often expose the same vulnerabilities as web apps, plus unique ones from their architectural patterns.
1) API Fundamentals
Understanding modern API architectures:
API Types:
REST (Representational State Transfer):
- Most common API style
- HTTP methods map to operations
- Stateless
- Resource-based URLs
GraphQL:
- Query language for APIs
- Single endpoint
- Client specifies exact data needed
- Strongly typed schema
SOAP (Simple Object Access Protocol):
- XML-based messaging
- Strict standards
- Legacy, still in enterprise
- WSDL describes services
gRPC:
- Binary protocol (Protocol Buffers)
- High performance
- Microservices communication
- Less common externally
REST API Conventions:
HTTP Methods → CRUD Operations:
GET /users → List all users
GET /users/123 → Get user 123
POST /users → Create new user
PUT /users/123 → Replace user 123
PATCH /users/123 → Update user 123 partially
DELETE /users/123 → Delete user 123
URL Patterns:
/api/v1/resources
/api/v1/resources/{id}
/api/v1/resources/{id}/subresources
Response Codes:
200 OK - Success
201 Created - Resource created
204 No Content - Success, no body
400 Bad Request - Client error
401 Unauthorized - Auth required
403 Forbidden - Auth failed
404 Not Found - Resource doesn't exist
500 Internal Server Error - Server bug
API Authentication:
Common API Auth Methods:
API Keys:
X-API-Key: abc123
?api_key=abc123
Simple but often leaked
Bearer Tokens (JWT):
Authorization: Bearer eyJhbG...
Stateless, contains claims
Common in modern APIs
Basic Authentication:
Authorization: Basic dXNlcjpwYXNz
Base64(username:password)
Simple, often over-permissioned
OAuth 2.0:
Authorization: Bearer [access_token]
Delegated authorization
Multiple grant types
HMAC Signatures:
Request signed with secret key
Timestamp prevents replay
More complex, more secure
Key insight: API authentication is often weaker than web authentication. API keys are frequently leaked in code.
2) API Discovery and Documentation
Finding and mapping API endpoints:
API Discovery Methods:
Documentation:
/api-docs
/swagger.json
/swagger/v1/swagger.json
/openapi.json
/v1/api-docs
/docs
/redoc
Common API Paths:
/api/
/api/v1/
/api/v2/
/rest/
/graphql
/query
Discovery from Client:
- Browser DevTools → Network tab
- Mobile app traffic → Proxy
- JavaScript files → API URLs
Swagger/OpenAPI Enumeration:
# Swagger UI often at:
/swagger-ui.html
/swagger-ui/
/api-docs/swagger-ui.html
# OpenAPI specification:
/openapi.json
/swagger.json
/api/swagger.json
# Parse OpenAPI spec for endpoints:
# Contains all routes, parameters, schemas
{
"paths": {
"/users": {
"get": {...},
"post": {...}
},
"/users/{id}": {
"get": {...},
"delete": {...}
}
}
}
# Tools:
# - Swagger Editor (import spec)
# - Postman (import OpenAPI)
# - Burp OpenAPI Parser extension
API Endpoint Fuzzing:
# Discover undocumented endpoints:
# Directory fuzzing:
ffuf -u https://api.target.com/FUZZ -w api-wordlist.txt
# Version fuzzing:
ffuf -u https://api.target.com/v1/FUZZ -w api-wordlist.txt
ffuf -u https://api.target.com/v2/FUZZ -w api-wordlist.txt
# Parameter fuzzing:
ffuf -u "https://api.target.com/users?FUZZ=value" -w params.txt
# SecLists API wordlists:
/usr/share/seclists/Discovery/Web-Content/api/
- api-endpoints.txt
- objects.txt
# Common undocumented endpoints:
/admin
/internal
/debug
/test
/health
/metrics
/status
/config
/env
Traffic Analysis:
# Capture API traffic from applications:
# Web applications:
1. Open browser DevTools
2. Network tab
3. Filter by XHR/Fetch
4. Browse application
5. Note all API calls
# Mobile applications:
1. Configure proxy (Burp)
2. Install CA certificate on device
3. Use mobile app
4. Capture all traffic
# Thick clients:
1. Wireshark or proxy
2. SSL interception may be harder
3. Look for certificate pinning
# Document:
- All endpoints found
- Parameters used
- Authentication method
- Request/response formats
Key insight: API documentation often reveals more than intended. Undocumented endpoints may lack security controls.
3) OWASP API Security Top 10
The top API-specific vulnerabilities:
OWASP API Security Top 10 (2023):
API1: Broken Object Level Authorization
(BOLA/IDOR - accessing others' objects)
API2: Broken Authentication
(Weak auth, token issues)
API3: Broken Object Property Level Authorization
(Mass assignment, excessive data exposure)
API4: Unrestricted Resource Consumption
(No rate limiting, DoS)
API5: Broken Function Level Authorization
(Accessing admin functions)
API6: Unrestricted Access to Sensitive Business Flows
(Abusing business logic at scale)
API7: Server Side Request Forgery
(SSRF via API)
API8: Security Misconfiguration
(Verbose errors, CORS issues)
API9: Improper Inventory Management
(Old API versions, shadow APIs)
API10: Unsafe Consumption of APIs
(Trusting third-party APIs)
API1: BOLA (IDOR in APIs):
# Most common API vulnerability
# Example:
GET /api/users/123/orders
# Returns user 123's orders
# Attack:
GET /api/users/124/orders
# Returns user 124's orders (BOLA!)
# Testing:
1. Create two accounts
2. Note object IDs for each
3. Try accessing account B's objects with account A's token
# Variations:
GET /api/orders/1001 # Direct object access
POST /api/orders/1001/refund # Action on others' objects
DELETE /api/users/124 # Delete others' resources
# UUIDs don't help:
GET /api/users/550e8400-e29b-41d4-a716-446655440000
# Still vulnerable if no authorization check
API3: Mass Assignment:
# Modifying properties you shouldn't
# Normal request:
POST /api/users
{"name": "John", "email": "john@test.com"}
# Mass assignment attack:
POST /api/users
{
"name": "John",
"email": "john@test.com",
"role": "admin", # Added
"isVerified": true, # Added
"credits": 999999 # Added
}
# If API binds all properties:
# Attacker becomes admin with unlimited credits!
# Testing:
1. Find object schema (docs, responses)
2. Identify sensitive fields
3. Try adding them to requests
4. Check if values are accepted
# Common targets:
role, isAdmin, permissions
balance, credits
verified, approved
password (change others')
API4: Rate Limiting Issues:
# No limits = abuse opportunities
# Brute force:
POST /api/login (unlimited attempts)
# Resource exhaustion:
GET /api/reports/generate (expensive operation)
POST /api/export (generates large files)
# Data scraping:
GET /api/users?page=1
GET /api/users?page=2
... (enumerate all data)
# Testing:
1. Send many requests rapidly
2. Check for 429 Too Many Requests
3. Test different endpoints
4. Check authenticated vs unauthenticated
# Tools:
# Burp Intruder
# ffuf with high thread count
# Custom scripts
Key insight: APIs often have weaker controls than web UIs because developers assume API clients are trusted.
4) GraphQL Security
Testing GraphQL APIs:
GraphQL Basics:
Single endpoint: /graphql
Query (read data):
query {
user(id: 123) {
name
email
}
}
Mutation (modify data):
mutation {
createUser(name: "Test", email: "test@test.com") {
id
}
}
# All operations via POST to /graphql
GraphQL Introspection:
# Introspection reveals entire schema!
# Introspection query:
{
__schema {
types {
name
fields {
name
type {
name
}
}
}
}
}
# Get all queries and mutations:
{
__schema {
queryType {
fields {
name
args {
name
type { name }
}
}
}
mutationType {
fields {
name
}
}
}
}
# Tools:
# - GraphQL Voyager (visualize schema)
# - GraphiQL (interactive explorer)
# - Burp: InQL extension
GraphQL Vulnerabilities:
# IDOR in GraphQL:
query {
user(id: "other-user-id") {
name
email
password # Might be returned!
}
}
# Excessive data exposure:
query {
users {
name
email
password
ssn
creditCard
}
}
# May return sensitive fields
# Nested query DoS:
query {
user(id: 1) {
friends {
friends {
friends {
friends {
name
}
}
}
}
}
}
# Exponential database load
# Batch queries:
query {
user1: user(id: 1) { name }
user2: user(id: 2) { name }
user3: user(id: 3) { name }
# ... enumerate many users in one request
}
GraphQL Injection:
# SQL injection in arguments:
query {
user(name: "admin' OR '1'='1") {
name
email
}
}
# NoSQL injection:
query {
user(filter: "{\"$gt\": \"\"}") {
name
}
}
# Testing:
# Inject into every argument
# Look for errors revealing backend
Key insight: GraphQL introspection often reveals everything. Disable it in production or test everything it reveals.
5) API Testing Methodology
Systematic approach to API security testing:
API Testing Phases:
1. Discovery
- Find documentation
- Capture traffic
- Enumerate endpoints
- Identify authentication
2. Analysis
- Map all endpoints
- Identify object references
- Note authentication/authorization
- Document data flows
3. Authentication Testing
- Token analysis
- Session management
- Brute force protection
- Token leakage
4. Authorization Testing
- BOLA/IDOR
- Function-level access
- Mass assignment
- Horizontal/vertical escalation
5. Input Validation
- Injection attacks
- Parameter tampering
- Data type manipulation
6. Business Logic
- Rate limiting
- Workflow bypass
- Resource exhaustion
Testing Tools:
# Burp Suite:
- Proxy for traffic capture
- Repeater for manual testing
- Intruder for fuzzing
- Extensions: InQL, OpenAPI Parser, Autorize
# Postman:
- API collection management
- Environment variables
- Automated testing
- Import OpenAPI specs
# OWASP ZAP:
- API scanning
- OpenAPI import
- Active scanning
# Specialized:
- Arjun: Parameter discovery
- ffuf: Endpoint fuzzing
- jwt_tool: JWT testing
- GraphQL Voyager: Schema visualization
# Command line:
curl -X GET "https://api.target.com/users" \
-H "Authorization: Bearer token123" \
-H "Content-Type: application/json"
# httpie (user-friendly curl):
http GET api.target.com/users "Authorization: Bearer token123"
API Testing Checklist:
Authentication:
□ Test without authentication
□ Test with invalid tokens
□ Test expired tokens
□ Test token from different user
□ Check token in URL vs header
□ Test API key exposure
Authorization:
□ BOLA on all object references
□ Mass assignment on create/update
□ Function-level access control
□ Cross-tenant access
□ HTTP method tampering
Input Validation:
□ SQL injection in parameters
□ NoSQL injection
□ Command injection
□ XXE (if XML accepted)
□ SSRF in URL parameters
Rate Limiting:
□ Authentication endpoints
□ Expensive operations
□ Data export features
□ Search functionality
Information Disclosure:
□ Verbose error messages
□ Stack traces
□ Internal IPs
□ Technology versions
□ Sensitive data in responses
Configuration:
□ CORS policy
□ HTTP security headers
□ TLS configuration
□ Old API versions accessible
Key insight: API testing requires methodical coverage. Every endpoint, every parameter, every method.
Real-World Context: API Security Today
API vulnerabilities in practice:
API Breaches: Major breaches have resulted from API vulnerabilities. Exposed GraphQL introspection revealing entire schemas. BOLA allowing access to millions of user records. API keys hardcoded in mobile apps.
Bug Bounty Trends: API vulnerabilities dominate bug bounty programs. BOLA/IDOR is consistently the top finding. GraphQL endpoints often yield multiple issues. Mass assignment provides quick wins.
Security Challenges: API security is hard because APIs expose logic directly. No UI abstraction layer. Every endpoint is an attack surface. Microservices multiply the problem.
MITRE ATT&CK Mapping:
- T1190 - Exploit Public-Facing Application: API exploitation
- T1552 - Unsecured Credentials: API key exposure
- T1119 - Automated Collection: API scraping
Key insight: APIs are the modern attack surface. If you can test APIs, you can test modern applications.
Guided Lab: API Security Testing
Practice API testing on vulnerable targets.
Step 1: API Discovery
# Find API documentation:
/swagger.json
/api-docs
/graphql (with introspection)
# Capture traffic from web/mobile client
# Use Burp proxy
# Document all endpoints found
Step 2: BOLA Testing
# Create two accounts
# Note object IDs for each
# Test accessing account B's data with account A's token:
GET /api/users/[B's ID]
GET /api/orders/[B's order ID]
DELETE /api/posts/[B's post ID]
# Document all BOLA findings
Step 3: Mass Assignment
# Find create/update endpoints
# Add extra parameters:
POST /api/users
{
"name": "test",
"role": "admin",
"isVerified": true
}
# Check if unauthorized fields accepted
Step 4: GraphQL Testing (if applicable)
# Run introspection query
# Map entire schema
# Test BOLA on queries
# Check for sensitive fields exposed
# Test nested query DoS
Step 5: PortSwigger Labs & Practice
# PortSwigger API testing labs
# OWASP crAPI (Completely Ridiculous API)
# https://github.com/OWASP/crAPI
# Test for all OWASP API Top 10
Reflection (mandatory)
- How did API testing differ from web application testing?
- Which OWASP API Top 10 issue did you find most?
- How valuable was API documentation for testing?
- What surprised you about API security?
Week 10 Quiz
Test your understanding of API Security Testing and the OWASP API Top 10.
Format: 10 multiple-choice questions. Passing score: 70%. Time: Untimed.
Take QuizWeek 10 Outcome Check
By the end of this week, you should be able to:
- Understand REST and GraphQL API architectures
- Discover and document API endpoints
- Test for OWASP API Security Top 10 issues
- Exploit BOLA and mass assignment vulnerabilities
- Test GraphQL for security issues
- Apply systematic API testing methodology
Next week: Modern Web Frameworks—testing React, Angular, and the technologies driving today's applications.
🎯 Hands-On Labs (Free & Essential)
Apply what you learned through practical API security testing exercises. Complete these labs before moving to reading resources.
🕷️ PortSwigger: API Testing (5 LABS)
What you'll do: Learn API-specific vulnerabilities through hands-on practice:
• Exploiting API endpoint to bypass access controls
• Finding hidden API endpoints
• Mass assignment vulnerabilities
• Server-side parameter pollution
• API versioning exploitation
Why it matters: APIs are the backbone of modern applications. API
security testing requires different techniques than traditional web testing—understanding API
authentication, endpoints, parameters, and rate limiting is critical.
Time estimate: 2-3 hours
🎮 TryHackMe: GraphQL
What you'll do: Learn GraphQL security through practical exercises. Practice
introspection queries, query batching attacks, field suggestion abuse, and authorization bypass
in GraphQL APIs.
Why it matters: GraphQL is increasingly popular but introduces unique
security challenges. Understanding GraphQL-specific vulnerabilities (over-fetching,
introspection, batching) is essential for modern API testing.
Time estimate: 1.5-2 hours
🔧 OWASP CrAPI - Completely Ridiculous API
What you'll do: Practice on a deliberately vulnerable API with 15+ challenges
covering OWASP API Top 10. Exploit broken authentication, excessive data exposure, lack of
resources, mass assignment, and more.
Why it matters: Crapi provides realistic API vulnerabilities in a safe
environment. Unlike isolated labs, you'll need to discover vulnerabilities through API
exploration—developing real pentesting skills.
Time estimate: 3-4 hours
💡 Lab Strategy: Start with PortSwigger for core API vulnerability patterns. Then practice GraphQL-specific attacks. Finally, use Crapi for comprehensive API exploitation covering OWASP API Top 10. This progression builds complete API security testing skills: 550 total XP, 6-9 hours!
🛡️ Defensive Architecture & Secure Design Patterns
API security depends on strong identity, strict authorization, and centralized enforcement. Defensive design uses OAuth scopes, verified JWTs, and API gateways explainably and consistently.
OAuth 2.0 and JWT Best Practices
Token validation checklist:
- Validate issuer (iss) and audience (aud)
- Enforce expiry (exp) and not-before (nbf)
- Verify signature with rotating keys (JWKS)
- Scope APIs tightly (least privilege)
- Prefer Authorization Code + PKCE for public clients
API Gateway Security Controls
Gateway responsibilities:
- Authentication and token verification
- Rate limiting and quotas
- Request size and schema validation
- Centralized logging and anomaly detection
- Version control and deprecation enforcement
Real-World Incident: Twitter API Data Exposure (Disclosed 2022)
A Twitter API flaw allowed attackers to link emails and phone numbers to accounts at scale. Lessons learned: strict rate limits, scope enforcement, and audit logging for sensitive lookup endpoints are essential to prevent data harvesting.
Defensive Labs
Lab: Implement OAuth 2.0 with PKCE
Secure an API with Authorization Code + PKCE, then verify scope-based access on protected endpoints.
Lab: Harden JWT Validation
Enforce issuer/audience checks, expiry validation, and key rotation using JWKS. Demonstrate failed tokens.
Lab: Configure API Gateway Rate Limiting
Implement per-client quotas and burst limits, then verify 429 responses and alerting for abuse.
📚 Building on CSY101 Week-13: Threat model API data flows, scopes, and trust boundaries. CSY101 Week-14: Map controls to NIST 800-53 (AC/IA) and CIS Controls. CSY104 Week-11: Use CVSS to prioritize API fixes.
Reading Resources (Free + Authoritative)
Complete the required resources to build your foundation.
- OWASP API Security Top 10 (2023) · 60-90 min · 50 XP · Resource ID: csy203_w10_r1 (Required)
- PortSwigger - API Testing · 45-60 min · 50 XP · Resource ID: csy203_w10_r2 (Required)
- GraphQL Documentation · Reference · 25 XP · Resource ID: csy203_w10_r3 (Optional)
Lab: Comprehensive API Assessment
Goal: Perform complete API security assessment covering REST and GraphQL.
Part 1: Discovery
- Find API documentation
- Enumerate all endpoints
- Identify authentication method
- Map object types and relationships
- Document API version(s)
Part 2: Authentication Testing
- Test unauthenticated access
- Analyze token format (JWT?)
- Test token manipulation
- Check for brute force protection
Part 3: Authorization Testing
- Test BOLA on all object references
- Test function-level access control
- Test mass assignment
- Test cross-tenant access
Part 4: GraphQL (if applicable)
- Run introspection
- Map schema completely
- Test authorization on all queries
- Check for sensitive field exposure
- Test query complexity limits
Part 5: Additional Testing
- Rate limiting assessment
- Input validation testing
- Error handling review
- Security headers check
Deliverable (submit):
- API endpoint inventory
- Authentication analysis
- BOLA/authorization findings
- GraphQL assessment (if applicable)
- Prioritized remediation recommendations
Checkpoint Questions
- What is BOLA and why is it the #1 API vulnerability?
- What is mass assignment and how do you test for it?
- What information does GraphQL introspection reveal?
- How does API authentication typically differ from web authentication?
- What is the difference between API1 and API5 in OWASP API Top 10?
- How do you discover undocumented API endpoints?
Weekly Reflection
Reflection Prompt (200-300 words):
This week you learned API security testing—attacking the programmatic interfaces that power modern applications. You tested REST and GraphQL for authorization flaws and other API-specific vulnerabilities.
Reflect on these questions:
- APIs expose application logic directly without UI abstraction. How does this change the security testing approach?
- BOLA is conceptually simple (change an ID) yet remains the #1 API vulnerability. Why do developers keep making this mistake?
- GraphQL introspection reveals the entire schema. How should organizations balance developer convenience with security?
- API-first architecture means more attack surface. How should security teams adapt?
A strong reflection will connect API testing techniques to broader application security and development practices.
Verified Resources & Videos
- GraphQL Testing: InQL - Burp GraphQL Extension
- API Practice: OWASP crAPI - Vulnerable API
- JWT Testing: jwt_tool
API security testing is essential for modern application assessment. The techniques you've learned—BOLA testing, GraphQL exploitation, mass assignment—apply to virtually every contemporary application. As more applications become API-driven, these skills become increasingly valuable. Next week: modern web frameworks and their unique security considerations.