API Security Testing: What Professional Pentesters Actually Check

Your API is probably the most attacked surface in your application. APIs handle authentication, expose data, process transactions, and wire services together — all in a format that attackers can inspect and manipulate as easily as developers can.

But most security testing programs treat APIs as an afterthought. Automated scanners built for web applications miss a significant portion of API-specific vulnerabilities. Annual pentests cover the obvious categories but rarely have time to go deep on business logic. Internal security teams often don't have the API-specific attack knowledge that external pentesters bring.

This guide covers what professional pentesters actually test when they're handed an API to assess — and why many of these vulnerabilities survive automated scans.

The OWASP API Security Top 10

The OWASP API Security Top 10 is the standard reference for API-specific vulnerabilities. It's worth understanding this list not as a checklist but as a map of how APIs fail in practice.

API1: Broken Object Level Authorization (BOLA / IDOR)

This is the most common critical API vulnerability. It happens when an API endpoint accepts an object reference — an ID, UUID, or slug — without verifying that the requesting user is authorized to access that specific object.

A vulnerable pattern:

GET /api/accounts/12345/transactions
Authorization: Bearer [token for account 12345]

An attacker simply changes 12345 to 12346 and gets another user's transactions.

Why it survives automated scans: BOLA requires context. The scanner needs to know that account 12345 belongs to user A and 12346 belongs to user B. Static scanners don't know this. Professional pentesters create multiple test accounts and manually verify access patterns.

What pentesters test:

• All endpoints that accept object IDs in path, query, or body
• Horizontal escalation (same role, different object)
• Vertical escalation (lower-privileged role accessing higher-privileged data)
• Indirect references — can you enumerate objects by UUID collision, hash prediction, or sequential integers?

API2: Broken Authentication

Authentication failures specific to APIs differ from web application failures. APIs often implement their own auth mechanisms separate from the main application.

What pentesters test:

• JWT validation — can you use an expired token? Can you forge a token with alg: none? Is the signature verified?
• Token rotation — does the API invalidate old tokens on logout or password change?
• Rate limiting on authentication endpoints — can you brute-force credentials or OTP codes?
• Machine-to-machine (M2M) auth — API keys, service account tokens, OAuth client credentials
• Token scope — does a read-only token grant write access when you try it?
• Refresh token handling — can you use a revoked refresh token to get new access tokens?

API3: Broken Object Property Level Authorization

A subtler form of BOLA: you're authorized to access the object, but you shouldn't see or modify specific properties within it.

Classic example: A user can update their own profile. The PUT /api/users/{id} endpoint accepts a JSON body. A pentester tests whether they can include fields that shouldn't be writable:

{"name": "Alice", "role": "admin", "credits": 9999}

If the API doesn't filter incoming properties against an allowlist, mass assignment vulnerabilities exist.

What pentesters test:

• All writable endpoints — do they accept undocumented fields?
• Read-only properties — are admin-only fields returned in responses to standard users?
• Mass assignment on creation and update operations
• GraphQL introspection — what fields exist that aren't in the documented schema?

API4: Unrestricted Resource Consumption

APIs often have no limits on how many resources a request can consume.

What pentesters test:

• Pagination — can you request 100,000 records in a single response by setting limit=100000?
• Batch operations — can you process 10,000 items in one request?
• File operations — can you upload arbitrarily large files? Can you trigger server-side downloads of large remote URLs?
• Expensive queries — does filtering by regex or wildcard create O(n²) database operations?
• Missing rate limits on expensive endpoints (document generation, email sending, image processing)

API5: Broken Function Level Authorization

Role-based access control failures where users can invoke administrative or privileged API functions.

What pentesters test:

• Admin endpoints exposed to regular users (often at /api/admin/* but also scattered through standard endpoint trees)
• HTTP method confusion — an endpoint that allows GET for everyone; does PUT or DELETE also work?
• Version confusion — /api/v1/ enforces auth but /api/v2/ doesn't
• API versioning endpoints left open while production versions are secured

API6: Unrestricted Access to Sensitive Business Flows

APIs expose business logic directly. This is one of the hardest categories to catch with automation.

Examples:

• Can you replay a payment capture request to charge a card twice?
• Can you manipulate pricing in a checkout API?
• Can you exploit a referral program by self-referring?
• Can you submit an order without completing payment?
• Can you purchase more quantity than available stock by racing concurrent requests?

What pentesters do here: They read the business logic documentation, understand how the API is supposed to work, and then specifically attempt to violate those business rules. There's no scanner that does this.

API7: Server-Side Request Forgery (SSRF)

When an API makes server-side HTTP requests based on user-supplied input, attackers can target internal services.

Common patterns:

• Webhook configuration endpoints — {"url": "http://169.254.169.254/latest/meta-data/"}
• URL fetching features — document importers, link previewers, avatar URL fetchers
• Import/export features that accept remote URLs

What pentesters test:

• All endpoints that accept URLs or hostnames
• Cloud metadata endpoints (AWS: 169.254.169.254, GCP: metadata.google.internal)
• Internal service discovery — can you reach http://internal-api/, http://10.0.0.1/admin/?
• DNS rebinding — bypassing IP blocklists by resolving to internal addresses after initial validation

API8: Security Misconfiguration

API-specific misconfiguration that goes beyond standard web application hardening.

What pentesters check:

• CORS policy — does Access-Control-Allow-Origin: * cover authenticated endpoints?
• HTTP methods — does OPTIONS reveal more than it should?
• Error messages — do 500 errors return stack traces, database errors, or internal paths?
• HTTP security headers — X-Content-Type-Options, X-Frame-Options, CSP
• TLS configuration — outdated cipher suites, certificate validity, HSTS
• API versioning — are deprecated/debug versions still accessible?
• GraphQL introspection enabled in production

API9: Improper Inventory Management

APIs built by multiple teams, accumulated over time, tend to accumulate undocumented and forgotten endpoints.

What pentesters test:

• Endpoint discovery — brute-forcing common API paths, using historical data (Wayback Machine, GitHub search)
• Version enumeration — what happens when you request /api/v3/ when v2 is current?
• Swagger/OpenAPI spec discrepancies — documented vs. actual endpoints
• Mobile API endpoints — are there API endpoints called by mobile apps that aren't in the web documentation?
• Partner/third-party integrations — APIs opened for specific integrations and left accessible

API10: Unsafe Consumption of APIs

Often overlooked: if your application consumes third-party APIs, the security of those upstream APIs affects your application.

What pentesters check:

• Does your application validate responses from external APIs before processing them?
• Can a malicious third-party API response trigger SSRF, XSS, or injection attacks?
• Are OAuth flows with external providers properly validated?

Authentication Deep-Dives

JWT Testing

JSON Web Tokens are ubiquitous in API authentication. They're also commonly misconfigured.

Common JWT vulnerabilities:

Algorithm confusion: If the server accepts the alg claim from the token itself:

• alg: none — signature verification skipped entirely
• RS256 → HS256 confusion — sign with the public key when the server expects an HMAC

Key exposure: Is the JWT secret weak enough to brute-force? Is it stored in the codebase, environment variables passed to client-side bundles, or API responses?

Claim validation: Does the server verify exp (expiry), nbf (not before), iss (issuer), and aud (audience)?

Token storage: Are JWTs stored in localStorage (XSS-accessible) or httpOnly cookies (preferred)?

OAuth 2.0 Testing

OAuth flows introduce complex attack surfaces at the intersection of redirects, state management, and token exchange.

What pentesters check:

• State parameter — present, random, and validated? Without it, CSRF attacks on OAuth flows are trivial
• Redirect URI validation — localhost bypass, parameter pollution, open redirect chaining
• Authorization code reuse — can the same auth code be exchanged twice?
• Implicit flow — if still in use, tokens in URL fragments are logged by proxies and servers
• PKCE — is it required for public clients? Without it, authorization code interception attacks work

What Automated Scanners Miss

To be direct: automated scanners are good at finding symptoms of known vulnerability patterns. They are poor at:

1. Business logic vulnerabilities — BOLA, BFLA, API6 (unrestricted business flows) require understanding what the API is supposed to do
2. Second-order effects — an injection payload stored and executed later, a race condition that only manifests under concurrent load
3. Authorization logic — scanners don't create test users, don't understand role hierarchies, don't verify that user A can't access user B's data
4. Chained vulnerabilities — a combination of a low-severity misconfiguration and a medium-severity auth issue that together produce a critical finding
5. Custom authentication schemes — non-standard token formats, proprietary session management

This isn't an argument against automated scanning — it's an argument for using both. Automated scanning finds the infrastructure-level and common-pattern vulnerabilities at scale and speed. Manual testing by practitioners finds the business-logic and context-dependent issues.

Building a Practical API Security Program

Continuous automated baseline

Run automated API security scanning continuously — against staging, pre-production, or production with appropriate safeguards. This gives you:

• Infrastructure-level coverage (TLS, headers, error messages)
• Known vulnerability patterns (injection, SSRF indicators, common misconfigurations)
• Regression detection — catch newly introduced vulnerabilities as code changes

Annual or per-major-release manual penetration testing

Manual testing by practitioners who understand the OWASP API Top 10 should cover:

• Business logic review
• Authorization model verification (BOLA, BFLA)
• Authentication deep-dive (JWT, OAuth)
• Threat modeling — what are the highest-value targets in your specific API?

API inventory

Keep an up-to-date inventory of all API endpoints, including internal vs. external exposure, authentication requirements, data sensitivity, and service-to-service vs. client-facing designation. Without an inventory, you can't test what you don't know exists.