API Security Testing Checklist

Authentication & Authorization

• □ Verify strong password policies are enforced
• □ Test for multi-factor authentication bypass
• □ Check JWT token validation and expiration
• □ Verify session timeout and invalidation
• □ Test for privilege escalation vulnerabilities
• □ Verify proper role-based access control

Input Validation

• □ Test for SQL injection in all parameters
• □ Check for NoSQL injection vulnerabilities
• □ Test for XSS via API parameters
• □ Verify SSRF protection
• □ Test for command injection
• □ Check for path traversal vulnerabilities
• □ Verify type and format validation

Rate Limiting & Throttling

• □ Test rate limiting on authentication endpoints
• □ Verify API quota enforcement
• □ Test for bypass attempts via HTTP headers
• □ Check for distributed attack detection

Data Protection

• □ Verify TLS/SSL is enforced
• □ Check for sensitive data in logs
• □ Verify encryption of sensitive data at rest
• □ Test for information disclosure in error messages
• □ Check for proper response headers (CSP, etc.)

API-Specific Vulnerabilities

REST APIs

• □ Test HTTP methods (GET, POST, PUT, DELETE)
• □ Verify proper status codes
• □ Test for mass assignment
• □ Check for IDOR vulnerabilities

GraphQL APIs

• □ Test for query depth limiting
• □ Check for query complexity analysis
• □ Test for introspection disclosure
• □ Verify batch query limits

Business Logic

• □ Test for parameter tampering
• □ Verify workflow integrity
• □ Test for race conditions
• □ Check for economic abuse patterns

Documentation & Discovery

• □ Review API documentation for security guidance
• □ Test for exposed administrative endpoints
• □ Check for sensitive data in API documentation
• □ Verify proper versioning practices

Testing Tools

Recommended tools for API security testing:

• Burp Suite for manual testing
• OWASP ZAP for automated scanning
• Postman for API testing
• GraphQL-specific tools for GraphQL APIs

Conclusion

API security requires continuous attention and a testing approach that differs significantly from traditional web application security. APIs operate without browser-based user interfaces, which means many security controls built for web applications—CAPTCHAs, content security policies, same-origin policies—don't apply. APIs also tend to expose business logic directly: endpoints for creating accounts, transferring funds, modifying records, and accessing data. Common gaps we find in API security assessments include broken object-level authorization where users access other tenants' data by changing an ID parameter, excessive data exposure where endpoints return far more fields than the client needs, and insufficient rate limiting that enables automated scraping or brute-force attacks. Testing APIs requires methodical enumeration of every endpoint, parameter, and authentication mechanism, followed by manual testing of authorization boundaries and business logic flows that automated scanners consistently miss. Singapore organizations handling APIs that process personal data should also consider PDPA requirements and may benefit from a broader VAPT assessment around data protection and breach notification.

OWASP API Security Top 10 Coverage

The OWASP API Security Top 10 remains the baseline framework for API security testing. Published in 2023 and updated for the current threat landscape, it identifies the most critical API security risks: broken object-level authorization (BOLA), broken authentication, broken object property-level authorization, unrestricted resource consumption, and broken function-level authorization (BFLA). In our penetration testing engagements across Singapore, BOLA consistently ranks as the most common and most damaging finding. It occurs when an API endpoint accepts an object ID as a parameter but doesn't verify that the authenticated user should have access to that specific object. A tenant in a multi-tenant SaaS platform changes the account ID in their request and pulls another tenant's data. A patient in a healthcare portal modifies the record ID and reads someone else's medical history. Testing for BOLA requires methodical enumeration of every ID-based endpoint and systematic substitution of IDs belonging to other users or tenants.

Security misconfiguration ranks high in frequency even if the impact varies. Default credentials on API gateways, verbose error messages that reveal stack traces and internal paths, CORS headers set to wildcard origins, and debug endpoints left accessible in production. These issues are easy to find with automated scanners but often get missed because API testing gets deprioritized in favour of web application testing. Unrestricted resource consumption — the absence of rate limiting, payload size limits, or query complexity controls — enables denial-of-service conditions and creates opportunities for data scraping at scale. Every API security assessment should map findings directly to the OWASP Top 10 to ensure nothing gets missed.

Authentication Testing: Beyond the Basics

Authentication is where most API security assessments start, and for good reason. But checking whether an endpoint requires a token isn't enough. OAuth 2.0 implementations frequently contain flaws that allow token theft or privilege escalation. The most common issues we find include improper redirect URI validation (allowing an attacker to capture authorization codes), missing state parameter validation (enabling CSRF attacks against the OAuth flow), and refresh tokens that never expire or aren't rotated after use. JWT-based authentication introduces its own vulnerability class: algorithm confusion attacks where the server accepts an "alg: none" header, weak signing keys that can be brute-forced, and token payloads that contain sensitive claims (roles, permissions) without server-side validation. An API that trusts the JWT's role claim without checking it against a server-side session store is one token forgery away from admin access.

API keys present a different challenge. They're simple to implement but hard to secure properly. Keys embedded in mobile applications get extracted through reverse engineering. Keys stored in client-side JavaScript get scraped from page source. Keys committed to public repositories get harvested by automated scanners within minutes. Testing API key security means checking for key rotation mechanisms, verifying that keys can be scoped to specific operations and endpoints, and confirming that compromised keys can be revoked without affecting other clients. Organizations subject to MAS TRM requirements should ensure their API authentication controls meet the guideline standards — something a thorough VAPT assessment should cover.

Authorization Testing: BOLA, BFLA, and Privilege Escalation

Authorization testing is where the real damage happens. Authentication confirms who you are. Authorization determines what you can do. APIs frequently implement authentication correctly but fail at authorization, especially at the object and property levels. Broken Object-Level Authorization (BOLA) means User A can access User B's resources by changing an ID. Broken Function-Level Authorization (BFLA) means a regular user can call admin-only endpoints. Testing for both requires two separate approaches: object-level testing (substituting IDs in requests to access other users' data) and function-level testing (attempting to call administrative or privileged endpoints with a low-privilege token). Both should be tested with multiple user roles to map the full authorization matrix.

Privilege escalation through API authorization flaws often chains with other vulnerabilities. An attacker finds a BOLA vulnerability that exposes admin user profiles, extracts password hashes or session tokens from those profiles, and uses them to authenticate as an admin. Or they find a BFLA vulnerability that grants access to an internal user management API, then create a new admin account for persistent access. These chains are why API security testing needs to be holistic — not just ticking boxes for individual vulnerability classes but testing how failures combine. The methodology matters: start with a low-privilege account, enumerate all accessible endpoints, test each for vertical and horizontal privilege escalation, and document which operations each role can perform versus what they should be able to perform. A well-structured penetration test will map these boundaries systematically.

GraphQL-Specific Security Testing

GraphQL APIs introduce a distinct set of security challenges that REST testing methodologies don't cover. The introspection query, which is enabled by default in most GraphQL implementations, exposes the entire schema — every type, field, mutation, and subscription — to anyone who queries it. In production, this is the equivalent of publishing your database schema to the internet. Disable introspection in production, or at minimum restrict it to authenticated internal users. Query depth and complexity attacks are the GraphQL equivalent of rate limiting bypasses: an attacker crafts a deeply nested query that causes exponential resource consumption on the server. A query that nests five levels of related objects can trigger thousands of database lookups from a single HTTP request.

Batch query attacks take this further by sending multiple operations in a single request, each triggering separate backend processing. Without query complexity analysis and depth limiting, a single GraphQL endpoint can be used to overwhelm backend services. Field-level authorization is another common gap: GraphQL resolves each field independently, and if the resolver doesn't check permissions for every field, sensitive data like email addresses, phone numbers, or internal IDs can leak through queries that mix authorized and unauthorized fields. Testing GraphQL APIs requires tools that understand the query language — standard REST scanners won't identify depth attacks, batch abuse, or field-level authorization failures. Use GraphQL-specific testing tools like GraphQL Cop, Clairvoyance, or custom scripts that systematically test depth, complexity, and authorization boundaries.

Real-World API Vulnerability Examples

The patterns we find in API penetration tests match what's being exploited in the wild. In 2024-2025, several high-profile breaches traced back to API authorization failures. A major financial services platform exposed customer data through an API endpoint that accepted account numbers as path parameters without verifying the authenticated user's relationship to that account. A healthcare portal returned full patient records — including diagnoses and prescriptions — through an API that only validated the session token without checking which patient's data was being requested. An e-commerce platform's admin API was accessible to any authenticated user because the authorization middleware only checked for a valid session, not for admin privileges.

These aren't exotic zero-days. They're straightforward authorization failures that automated scanners often miss because they require understanding the application's business logic. A scanner can tell you that an endpoint requires authentication. It cannot tell you whether User A should be able to access User B's order history. That requires manual testing by someone who understands the application's intended behaviour and can map where the implementation diverges from the design. This is why penetration testing and vulnerability scanning are different activities — scanning finds low-hanging fruit, testing finds the issues that actually lead to breaches.