API Penetration Testing: OWASP API Security Top 10 (2023) Explained

APIs have quietly become the most attacked surface in modern applications. Every mobile app, every microservice, every third-party integration—they all talk through APIs. And most of them are broken in predictable ways.

This post covers the OWASP API Security Top 10 (2023 edition), how I approach testing each one, and some real breaches that show why this stuff matters.

Part 2 of this series is a hands-on cheat sheet with actual commands you can use during testing.

Quick Reference

Why API Security is Different

Traditional web app testing focuses on things like XSS, CSRF, and session management. API testing overlaps but has its own flavor:

• Authentication is token-based — JWTs, API keys, OAuth tokens instead of session cookies
• Authorization failures are everywhere — BOLA/IDOR is the #1 API vulnerability by a huge margin
• The attack surface is hidden — No UI to click through, you’re working blind without documentation
• Microservices multiply risk — One app might have 50 internal APIs, each a potential entry point

API1:2023 — Broken Object Level Authorization (BOLA)

TL;DR: Change an object ID in a request while keeping your auth token. If you get someone else’s data, it’s vulnerable.

This is the big one. Roughly 40% of all API attacks exploit BOLA.

Testing Checklist

• Identify endpoints with object IDs (URL path, query params, JSON body)
• Create two test accounts (User A, User B)
• Capture request containing User A’s object ID
• Replay request with User B’s token + User A’s object ID
• Test ID variations: 0, 1, -1, admin, null, ../
• Check encoded formats: base64 decode → modify → re-encode
• Use Burp Autorize for automated cross-session testing

API2:2023 — Broken Authentication

TL;DR: Forge or crack tokens, exploit weak JWT implementations, bypass authentication entirely.

This covers everything wrong with how APIs verify identity: weak JWT implementations, missing token validation, credential stuffing vulnerabilities.

Testing Checklist

• Decode JWT and inspect header + payload
• Test alg: none attack (remove signature)
• Try algorithm confusion (RS256 → HS256 with public key as secret)
• Crack weak secrets with hashcat/jwt_tool
• Test kid parameter for SQLi and path traversal
• Replay expired tokens
• Use token after logout
• Check for missing rate limiting on login

{"alg":"HS256", "kid":"key1' UNION SELECT 'secret'--"}
{"alg":"HS256", "kid":"../../../etc/passwd"}

API3:2023 — Broken Object Property Level Authorization

TL;DR: The API returns too much data or accepts fields it shouldn’t. Check responses for sensitive fields, try adding "role": "admin" to requests.

This combines two related issues: Excessive Data Exposure and Mass Assignment.

Testing Checklist

• Inspect all API responses for sensitive fields (password_hash, ssn, internal_id, role)
• Compare response fields vs what the UI displays
• Try adding "role": "admin" to registration/update requests
• Test common fields: isAdmin, verified, credits, discount, price
• Use Arjun to discover hidden parameters
• Check if you can modify fields that should be read-only

{"isAdmin": true}
{"role": "admin"}
{"permissions": ["read", "write", "delete"]}
{"verified": true}
{"credits": 99999}
{"discount": 100}
{"price": 0}
{"approved": true}

API4:2023 — Unrestricted Resource Consumption

TL;DR: No rate limiting, no pagination limits, no query complexity limits. Fire 100 requests and see if you get blocked.

Testing Checklist

• Fire 100 login attempts in 10 seconds — any 429 responses?
• Test pagination: ?limit=999999, ?per_page=-1
• For GraphQL: send deeply nested queries
• Try GraphQL batching to bypass rate limits
• Check if expensive operations (reports, exports) are rate limited
• Test file upload size limits

mutation {
  a: login(user:"admin", pass:"pass1") { token }
  b: login(user:"admin", pass:"pass2") { token }
  c: login(user:"admin", pass:"pass3") { token }
}

API5:2023 — Broken Function Level Authorization (BFLA)

TL;DR: BOLA is about accessing other users’ data. BFLA is about accessing other users’ functions. Can a regular user hit admin endpoints?

Testing Checklist

• Fuzz for admin paths: /api/admin/*, /api/internal/*, /api/debug/*
• Try accessing admin endpoints with regular user token
• Test HTTP method tampering: if GET works, try DELETE/PUT/PATCH
• Check if different Content-Types bypass authorization
• Use kiterunner for endpoint discovery
• Compare functionality between user roles

/api/admin/users
/api/admin/config
/api/internal/metrics
/api/debug
/api/management/users
/api/v1/admin/

API6:2023 — Unrestricted Access to Sensitive Business Flows

TL;DR: Can you script actions that should require human interaction? Automate purchases, abuse referrals, spam reviews.

Testing Checklist

• Can you automate the checkout flow?
• Test coupon/promo code reuse
• Try referring yourself
• Can you create accounts without email verification?
• Test for race conditions in financial operations
• Check if human verification (CAPTCHA) can be bypassed

API7:2023 — Server-Side Request Forgery (SSRF)

TL;DR: Any parameter that takes a URL is an SSRF candidate. Test with cloud metadata endpoints.

Testing Checklist

• Find URL input parameters (webhooks, imports, previews)
• Test AWS metadata: http://169.254.169.254/latest/meta-data/
• Test GCP metadata: http://metadata.google.internal/...
• Try filter bypasses: decimal IP, IPv6, URL encoding
• Scan internal ports via SSRF
• Use Burp Collaborator for blind SSRF

http://2130706433/           (decimal IP = 127.0.0.1)
http://[::1]/                (IPv6 localhost)
http://127.0.0.1%00@evil.com/
http://localhost%23@evil.com/
http://127.1/
http://0/

API8:2023 — Security Misconfiguration

TL;DR: The grab bag of “you left something open.” Test CORS, find exposed docs, trigger verbose errors.

Testing Checklist

• Test CORS: send Origin: https://evil.com, check response headers
• Find exposed docs: /swagger.json, /api-docs, /graphql
• Trigger verbose errors with malformed input
• Check for debug endpoints
• Verify unnecessary HTTP methods are disabled
• Check security headers (HSTS, X-Content-Type-Options)

Access-Control-Allow-Origin: https://evil.com
Access-Control-Allow-Credentials: true

API9:2023 — Improper Inventory Management

TL;DR: Shadow APIs and forgotten versions. The new v2 has auth, but v1 is still running without it.

Testing Checklist

• Enumerate versions: /api/v1/, /api/v2/, /api/beta/
• Compare security between versions (auth, rate limits)
• Use kiterunner to discover shadow APIs
• Check subdomains: api-dev., api-staging., internal-api.
• Look for documentation of deprecated endpoints
• Test if old versions have weaker security controls

API10:2023 — Unsafe Consumption of APIs

TL;DR: What happens when the API consumes external data? If it trusts third-party data without validation, inject payloads through the back door.

Testing Checklist

• Identify third-party data sources (webhooks, imports, feeds)
• If you control a webhook endpoint, return malicious payloads
• Test if external data is validated (XSS, SQLi, command injection)
• Check if third-party API failures are handled securely
• Look for SSRF via third-party URL parameters

Real-World Breaches

My Testing Methodology

What’s Next

In Part 2, I break down each vulnerability into step-by-step testing commands you can use during engagements. It’s the practical cheat sheet I wish I had when I started learning this stuff.

Questions or feedback? Find me on GitHub.