APIs are the attack surface most likely to be undertested in your application. While web application firewalls and front-end security get significant attention, the API layer — where your actual business logic and data live — is frequently exposed with fewer controls, less monitoring, and weaker authentication than the UI it supports. The OWASP API Security Top 10 is the definitive framework for API vulnerability assessment. Here is how to test for each category.
API1 — Broken Object Level Authorization (BOLA / IDOR)
The most common and impactful API vulnerability. The application fails to verify that the authenticated user is authorised to access a specific object, allowing any user to access any other user's resources by manipulating object identifiers.
GET /api/v2/users/1338/documents ← Change your own ID to another user's Authorization: Bearer <your_token> → 200 OK [Returns user 1338's documents] ← BOLA confirmed
Test approach: Authenticate as User A. Identify all API endpoints that accept object identifiers (user IDs, document IDs, account numbers). Substitute your identifiers with those of another known user. Any 200 response returning the other user's data is a confirmed BOLA finding.
API2 — Broken Authentication
Authentication mechanisms that are weak, improperly implemented, or bypassable. Common issues include: JWT signature not verified, tokens that don't expire, weak password policies with no brute-force protection, OAuth flows with state parameter omitted.
JWT header.payload.none ← Algorithm: none bypass JWT with expired exp claim ← Token expiry not verified POST /api/auth/login with 10,000 passwords ← No rate limiting
API3 — Broken Object Property Level Authorization
The API authorises access to the object but doesn't filter which properties the user can see or set. An attacker can read sensitive properties (internal flags, other users' data within a shared object) or write privileged properties (role, account_balance, is_admin).
PATCH /api/v2/users/me
{"display_name": "Attacker", "role": "admin", "is_verified": true}
→ 200 OK ← Mass assignment — privileged fields acceptedAPI4 — Unrestricted Resource Consumption
No rate limiting, no request size limits, no query complexity limits. Allows DoS attacks, credential stuffing at scale, and automated enumeration of sensitive data.
Test approach: Send 500 password reset requests per minute to a single account. Send 10MB request bodies. Send GraphQL queries with deeply nested selections. Check for HTTP 429 responses and automatic IP-based throttling.
API5 — Broken Function Level Authorization
Administrative or privileged functions are accessible to unprivileged users because the API relies on obscurity rather than enforced authorisation. Common in APIs with predictable admin endpoint naming.
GET /api/v2/users/me → 200 (your profile) GET /api/v2/admin/users → Should 403, returns 200 POST /api/v2/admin/users/delete → Deletes any user account
API6 — Unrestricted Access to Sensitive Business Flows
Business logic vulnerabilities that allow abuse of core workflows — purchasing at manipulated prices, skipping payment steps, triggering actions without required prerequisites. These cannot be detected by automated scanners.
Test approach: Map the complete business workflow. Attempt to skip steps, repeat steps, replay responses, and manipulate sequencing. Test whether server-side validation enforces the same rules as client-side.
API7 — Server Side Request Forgery (SSRF)
The API accepts user-controlled URLs and makes server-side requests to them, potentially reaching internal services, cloud metadata endpoints, or private network resources.
POST /api/v2/webhook
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
→ 200 OK [Returns AWS IAM credentials for the server role]API8 — Security Misconfiguration
Default API configurations, verbose error messages containing stack traces, permissive CORS headers, missing security headers, HTTP instead of HTTPS, and debug endpoints left enabled in production.
API9 — Improper Inventory Management
Shadow APIs — undocumented, deprecated, or forgotten endpoints — that retain access to sensitive data and lack the security controls applied to current API versions. Often found via JavaScript analysis, mobile app decompilation, or historical DNS records.
Active API: /api/v3/users ← Well-tested, has auth Shadow API: /api/v1/users ← Deprecated, no auth check, full data access Legacy endpoint: /internal/admin ← Never documented, IP restriction only
API10 — Unsafe Consumption of APIs
Your application blindly trusts and consumes data from third-party APIs without validation, allowing a compromised upstream provider to inject data that exploits your application.
Building an API Security Testing Program
The most effective API security programs combine automated scanning (to catch common misconfigurations and known CVE patterns) with manual testing (for BOLA, business logic, and chained vulnerabilities). Test every new API endpoint before it reaches production. Maintain an authoritative API inventory and audit it quarterly for shadow and deprecated endpoints. Include API security requirements in your developer security training and code review checklists.
Key Takeaways
- This post covers practical, actionable guidance for security and engineering teams.
- All findings and techniques are mapped to recognised frameworks (OWASP, NIST, ISO).
- Contact Vynox Security to test your systems against the vulnerabilities described here.