API Securitypenetration testingOWASPautomationEN

API Security Testing: The Complete Guide

March 12, 202618 minVAHREST Team

Why API Security Testing Matters

APIs are the connective tissue of modern software. Every mobile app, single-page application, microservice architecture, and third-party integration relies on APIs. This ubiquity makes them a prime target for attackers.

According to industry reports, API-related breaches have increased by over 300% between 2022 and 2025. The average cost of an API breach exceeds $4.5 million when factoring in remediation, regulatory fines, and reputational damage.

Yet most organizations still treat API security as an afterthought -- a box to check before release rather than a continuous practice. This guide covers the full spectrum of API security testing, from methodology to tooling to organizational practices.

API Security Testing Methodology

A structured approach to API security testing follows five phases:

Phase 1: Reconnaissance and Discovery

Before testing, you need a complete picture of your API surface.

Passive Reconnaissance:

Review OpenAPI/Swagger specifications
Analyze JavaScript bundles for hardcoded endpoints
Check public repositories for API documentation
Monitor DNS for API-related subdomains (api., gateway., internal.)

Active Discovery:

Crawl the application to discover API calls
Fuzz common API paths (/api/v1/, /graphql, /internal/)
Use tools like Kiterunner with wordlists specific to API frameworks
Analyze mobile app traffic for hidden endpoints

Shadow API Detection:

Compare discovered endpoints against documented APIs
Identify deprecated versions still accessible (/v1/ when /v3/ is current)
Look for debug, test, and staging endpoints in production

bash

# Discover API endpoints with Kiterunner
kr scan https://api.target.com -w routes-large.kite

# Fuzz API paths with ffuf
ffuf -u https://api.target.com/FUZZ -w api-wordlist.txt \
  -mc 200,201,301,302,401,403

Phase 2: Authentication and Authorization Testing

Authentication and authorization vulnerabilities account for over 60% of critical API findings.

JWT Testing

JSON Web Tokens are the most common API authentication mechanism -- and one of the most frequently misconfigured.

Common JWT Vulnerabilities:

1Algorithm confusion (CVE-2015-9235): The server accepts tokens signed with "none" algorithm
2Weak signing keys: Keys that can be brute-forced (jwt_tool, hashcat)
3Missing expiration: Tokens without exp claim or with excessive TTL
4Missing audience/issuer validation: Tokens accepted across services
5Key confusion (RS256 to HS256): Using the public key as HMAC secret

bash

# Test for "none" algorithm
python3 jwt_tool.py <token> -X a

# Brute-force weak HMAC secret
hashcat -a 0 -m 16500 <token> wordlist.txt

# Test for key confusion
python3 jwt_tool.py <token> -X k -pk public.pem

OAuth 2.0 Testing

OAuth implementations introduce their own attack surface:

Open redirect in authorization endpoint: Steal authorization codes
CSRF in OAuth flow: Force account linking
Token leakage via Referer header: Authorization codes in URL parameters
Insufficient scope validation: Tokens with excessive permissions
PKCE bypass: Code exchange without code_verifier

Broken Object Level Authorization (BOLA)

BOLA is the #1 API vulnerability. Testing requires:

1Create two accounts with the same role
2Authenticate as User A, obtain their resource IDs
3Attempt to access User A's resources using User B's token
4Test across all CRUD operations (GET, PUT, PATCH, DELETE)
5Test both direct ID references and indirect references (nested resources)

bash

# Direct BOLA test
curl -H "Authorization: Bearer <user_b_token>" \
  https://api.target.com/v1/users/USER_A_ID/profile

# Nested resource BOLA
curl -H "Authorization: Bearer <user_b_token>" \
  https://api.target.com/v1/organizations/ORG_A/invoices/INV_123

Broken Function Level Authorization (BFLA)

Test whether lower-privileged users can access administrative functions:

Enumerate admin endpoints (/admin/, /manage/, /internal/)
Test HTTP method switching (GET to PUT/DELETE)
Test role escalation (modify role field in profile update)
Check for missing authorization on new endpoints

Phase 3: Input Validation and Injection Testing

APIs that accept user input are vulnerable to injection attacks.

SQL Injection

Despite being well-known, SQLi remains prevalent in APIs:

bash

# Test ORDER BY injection
curl "https://api.target.com/v1/products?sort=name;SELECT+pg_sleep(5)--"

# Test filter parameter injection
curl "https://api.target.com/v1/users?filter=id%27+OR+1%3D1--"

# JSON body injection
curl -X POST https://api.target.com/v1/search \
  -H "Content-Type: application/json" \
  -d '{"query": "test\"; DROP TABLE users;--"}'

NoSQL Injection

Increasingly common with MongoDB-backed APIs:

bash

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

# Regex injection
curl "https://api.target.com/v1/users?name[$regex]=.*"

Server-Side Request Forgery (SSRF)

APIs that fetch external resources are SSRF targets:

bash

# Cloud metadata access
curl -X POST https://api.target.com/v1/webhooks \
  -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

# Internal service discovery
curl -X POST https://api.target.com/v1/import \
  -d '{"source_url": "http://internal-service:8080/admin"}'

# DNS rebinding bypass
curl -X POST https://api.target.com/v1/fetch \
  -d '{"url": "http://your-rebinding-domain.com"}'

Mass Assignment

Test whether the API accepts fields that should be protected:

bash

# Attempt to escalate privileges
curl -X PATCH https://api.target.com/v1/users/me \
  -H "Authorization: Bearer <token>" \
  -d '{"name": "John", "role": "admin", "is_verified": true, "balance": 99999}'

Phase 4: Business Logic Testing

Business logic vulnerabilities cannot be found by automated scanners alone. They require understanding of the application's intended behavior.

Rate Limiting and Resource Exhaustion

bash

# Test rate limiting on authentication
for i in $(seq 1 1000); do
  curl -s -o /dev/null -w "%{http_code}" \
    -X POST https://api.target.com/v1/auth/login \
    -d '{"email": "test@test.com", "password": "wrong'$i'"}'
done

# Test pagination abuse
curl "https://api.target.com/v1/transactions?limit=999999999&offset=0"

# Test resource exhaustion via file upload
dd if=/dev/zero bs=1M count=1000 | \
  curl -X POST https://api.target.com/v1/upload \
  -F "file=@-;filename=large.bin"

Race Conditions

APIs are particularly susceptible to race conditions in:

Payment processing (double-spend)
Coupon/promo code redemption
Account balance operations
Inventory management

bash

# Race condition test with parallel requests
seq 1 20 | xargs -P 20 -I {} curl -s \
  -X POST https://api.target.com/v1/redeem-coupon \
  -H "Authorization: Bearer <token>" \
  -d '{"code": "DISCOUNT50"}'

Price Manipulation

Modify price fields in cart/checkout requests
Apply negative quantities
Change currency codes
Manipulate discount calculations

Workflow Bypass

Skip required steps (email verification, payment)
Replay completed transactions
Access resources before required preconditions are met

Phase 5: Configuration and Infrastructure

TLS Configuration

bash

# Test TLS configuration
testssl.sh --protocols --ciphers --vulnerabilities https://api.target.com

# Check certificate details
openssl s_client -connect api.target.com:443 -servername api.target.com

Verify:

TLS 1.2+ only (no SSLv3, TLS 1.0, TLS 1.1)
Strong cipher suites (no RC4, 3DES, NULL)
Valid certificate chain
HSTS header present
Certificate pinning for mobile clients

Security Headers

Check for:

Strict-Transport-Security (HSTS)
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy
Cache-Control: no-store for sensitive responses
Absence of Server and X-Powered-By headers

CORS Configuration

bash

# Test CORS with arbitrary origin
curl -H "Origin: https://evil.com" \
  -I https://api.target.com/v1/user/profile

# Check if credentials are reflected
curl -H "Origin: https://evil.com" \
  -H "Access-Control-Request-Method: POST" \
  -X OPTIONS https://api.target.com/v1/sensitive-data

Dangerous patterns:

Access-Control-Allow-Origin: * with credentials
Origin reflection without whitelist
null origin allowed

Error Handling

Stack traces in production responses
Database error messages exposed
Internal IP addresses leaked
Framework version information disclosed

DAST vs SAST vs SCA: Complementary Approaches

No single approach catches everything. A mature security testing program combines multiple techniques.

Dynamic Application Security Testing (DAST)

DAST tests the running application from the outside, simulating attacker behavior.

Strengths:

Finds runtime vulnerabilities (BOLA, authentication bypass, SSRF)
Technology-agnostic -- works regardless of implementation language
Discovers configuration issues (CORS, TLS, security headers)
Can find business logic flaws with proper configuration

Limitations:

Cannot see source code
Coverage depends on endpoint discovery
May miss code paths that require specific conditions
Can cause side effects in production

Tools: ZAP, Nuclei, Schemathesis, Burp Suite, VAHREST

Static Application Security Testing (SAST)

SAST analyzes source code without executing it.

Strengths:

Complete code coverage
Finds vulnerabilities early in development
Can detect hardcoded secrets, insecure patterns
No runtime environment required

Limitations:

High false positive rate (10-30% is common)
Language-specific -- needs separate tooling per language
Cannot find configuration or deployment issues
Misses runtime behavior (authentication, authorization)

Tools: Semgrep, SonarQube, CodeQL, Checkmarx

Software Composition Analysis (SCA)

SCA identifies known vulnerabilities in third-party dependencies.

Strengths:

Fast identification of CVEs in dependencies
License compliance checking
Continuous monitoring with dependency databases
Low false positive rate

Limitations:

Only finds known vulnerabilities (not zero-days)
Cannot determine if vulnerable code path is reachable
Requires accurate dependency manifests

Tools: Trivy, Snyk, Dependabot, Gitleaks

The Right Combination

For comprehensive API security testing:

Phase	Approach	Frequency
Development	SAST + SCA	Every commit (CI/CD)
Pre-release	DAST (express scan)	Every release
Production	DAST (full scan)	Weekly/Monthly
Continuous	SCA monitoring	Real-time alerts

API Fuzzing

Fuzzing -- sending malformed, unexpected, or random data -- is one of the most effective techniques for finding API vulnerabilities that structured testing misses.

Types of API Fuzzing

Schema-based fuzzing: Generate test cases from OpenAPI specifications. Each parameter is tested with boundary values, type mismatches, and malformed data.

Mutation-based fuzzing: Take valid API requests and systematically modify fields, headers, and parameters.

Generation-based fuzzing: Create requests from scratch based on API grammar, including invalid combinations.

What Fuzzing Finds

Unhandled exceptions and crashes
Buffer overflows and memory corruption
Input validation bypasses
Unexpected error responses with sensitive data
Denial of service conditions
Edge cases in business logic

Fuzzing Strategy

1Start with schema-based fuzzing using the OpenAPI spec
2Fuzz authentication parameters (tokens, headers, cookies)
3Fuzz path parameters (IDs, slugs, filenames)
4Fuzz query parameters (filters, pagination, sorting)
5Fuzz request bodies (JSON fields, nested objects, arrays)
6Fuzz headers (Content-Type, Accept, custom headers)

GraphQL-Specific Testing

GraphQL APIs introduce unique security considerations:

Introspection

bash

# Check if introspection is enabled
curl -X POST https://api.target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "{ __schema { types { name fields { name } } } }"}'

Introspection should be disabled in production.

Query Depth and Complexity

graphql

# Deeply nested query (potential DoS)
{
  user(id: 1) {
    friends {
      friends {
        friends {
          friends {
            name
          }
        }
      }
    }
  }
}

Test for:

Maximum query depth limits
Query complexity limits
Batch query limits
Field-level authorization

GraphQL Injection

bash

# Test for injection in variables
curl -X POST https://api.target.com/graphql \
  -H "Content-Type: application/json" \
  -d '{"query": "query { user(id: \"1 OR 1=1\") { email } }"}'

Building an API Security Testing Program

Shift-Left: Security in Development

Integrate security testing into your development workflow:

1Pre-commit: Secrets scanning (Gitleaks), linting for security patterns
2CI/CD: SAST + SCA on every pull request
3Staging: DAST scan before deployment to production
4Production: Continuous monitoring and periodic full scans

Metrics to Track

Mean Time to Detect (MTTD): How quickly vulnerabilities are found
Mean Time to Remediate (MTTR): How quickly they are fixed
Vulnerability Density: Vulnerabilities per API endpoint
Coverage: Percentage of endpoints tested
False Positive Rate: Accuracy of testing tools
Recurrence Rate: How often the same vulnerability type reappears

Common Pitfalls

1Testing only in staging: Production configurations differ. Test both.
2Ignoring business logic: Automated tools miss logic flaws. Combine automation with manual review.
3One-time testing: APIs change constantly. Test continuously.
4Incomplete endpoint coverage: Shadow APIs are a real threat. Discover before testing.
5Ignoring third-party APIs: Your security is only as strong as your weakest integration.

Automation with VAHREST

VAHREST integrates 35 security tools into a unified platform designed specifically for API security testing.

How It Works

1Discovery. Provide your API base URL and optionally upload an OpenAPI spec. VAHREST automatically discovers endpoints through crawling and fuzzing.

2Scanning. Choose a preset (Express for 5-minute checks, Full Security for comprehensive assessment) or configure custom tool combinations. VAHREST orchestrates DAST, SAST, SCA, and compliance checks in parallel.

3Analysis. Every finding is deduplicated, mapped to OWASP API Top 10 and CWE, scored with CVSS, and enriched with remediation guidance. AI-powered triage reduces false positives.

4Reporting. Generate reports in JSON, HTML, or PDF with regulatory overlays (PCI DSS, GDPR, GOST 57580, 152-FZ). Schedule recurring scans for continuous monitoring.

Key Capabilities

35 integrated tools -- ZAP, Nuclei, Schemathesis, Semgrep, Trivy, and more
6 scan presets -- from 5-minute Express to comprehensive Full Security
OWASP API Top 10 mapping -- every finding categorized
Compliance overlays -- PCI DSS 4.0, GOST 57580, 152-FZ
Shadow API detection -- discover undocumented endpoints
CI/CD integration -- API and scheduled scans

Conclusion

API security testing is not a one-time event but a continuous practice. The threat landscape evolves, APIs change, and new vulnerabilities emerge. A mature testing program combines:

Automated DAST for runtime vulnerability detection
SAST for code-level security analysis
SCA for dependency vulnerability management
Manual testing for business logic review
Continuous monitoring for real-time threat detection

Start with the highest-risk areas (authentication, authorization, input validation), automate what you can, and build security testing into your development lifecycle.

Try VAHREST for Free

Sign up and run your first API penetration test in 5 minutes. The free tier includes express scanning and OWASP API Top 10 reporting.

Try VAHREST for Free

Get Started Free

All articles