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

REST API Security Testing: Step-by-Step Methodology

Testing REST APIs requires a structured approach that moves from discovery through exploitation. Each phase builds on the previous one. Skipping ahead means missing context that determines whether a finding is real or a false positive.

Step 1: Reconnaissance and endpoint discovery. Before testing, you need a complete map of the API surface. Start with any published documentation. Swagger/OpenAPI specifications, Postman collections, and API documentation portals list endpoints, parameters, expected responses, and authentication requirements. If the organisation exposes a Swagger endpoint in production, that is your starting map. If not, you build one.

Endpoint enumeration comes next. Directory brute-forcing with wordlists targeting API paths like /api/v1/, /api/v2/, /api/internal/, and /api/admin/ uncovers undocumented endpoints. JavaScript files loaded by the frontend often contain hardcoded API routes that the documentation does not mention. Reviewing network traffic in Burp Suite while clicking through the application reveals the actual endpoints in use, including ones called by background processes. Check for old API versions that remain accessible. Version 1 endpoints frequently retain weaker controls than version 2 or 3, even after the organisation migrates users to the newer API.

Step 2: Authentication testing. Once you have the endpoint map, test how the API validates identity. If the API uses bearer tokens, capture a valid token and attempt to reuse it from a different IP address or client. Some APIs bind tokens to IP ranges and reject reuse attempts. Many do not, which means a stolen token works from anywhere until it expires.

JWT manipulation deserves specific attention. Decode the token and examine its header and payload. Test whether the server accepts a modified algorithm header. The classic attack is changing alg: RS256 to alg: HS256 and signing the token with the public key, which some servers mistakenly accept as an HMAC secret. Try submitting the token with the algorithm set to none and the signature stripped. servers with broken JWT libraries will accept unsigned tokens. Check token expiration. If a token issued at 9 AM on Monday still works on Friday, the refresh and revocation logic is broken. Examine the payload for claims that control access levels. If the token contains a role or admin claim, modify it and resend. If the server trusts the claim without validating it server-side, you have privilege escalation through token tampering.

Step 3: Authorization testing. Authentication tells the API who you are. Authorization determines what you can do. This is where the most damaging vulnerabilities live. Broken Object-Level Authorization (BOLA), also called IDOR, occurs when an API endpoint accepts an object identifier without verifying that the authenticated user should access that object.

Create two test accounts with different privilege levels. Authenticate as User A and capture requests that reference object IDs. Replace User A's object IDs with User B's object IDs. If the API returns User B's data, you have BOLA. Test every endpoint that accepts an ID parameter: /users/{id}, /accounts/{id}, /orders/{id}, /documents/{id}. Test both horizontal escalation (User A accessing User B's data at the same privilege level) and vertical escalation (regular user accessing admin-only endpoints).

Mass assignment is related. If the API accepts a JSON body with fields the frontend does not expose, try adding fields like "role": "admin" or "is_admin": true to a profile update request. If the backend binds the entire request body to the model without filtering, those fields get persisted and you just elevated your account.

Step 4: Parameter tampering and input testing. Every parameter in every request is an attack surface. Test string parameters for SQL injection, NoSQL injection, and command injection. Test numeric parameters by substituting strings, negative values, and extreme integers. Test boolean parameters by flipping them. Test enumeration parameters by submitting values outside the expected set.

SSRF testing targets endpoints that accept URLs as parameters. If the API fetches a URL you supply, try pointing it at internal IP addresses (http://169.254.169.254/ for AWS metadata, http://10.0.0.1/ for internal services). An API that blindly fetches and returns the content gives you access to internal resources that should not be reachable from the internet.

Path traversal works on endpoints that accept filenames or paths. ../../etc/passwd is the classic test, but modern APIs that serve files through object storage (S3 presigned URLs, Azure blob storage) can also be vulnerable if the signing logic allows directory traversal in the object key.

Step 5: Rate limit and quota bypass. Test whether the API enforces rate limits on authentication endpoints, data access endpoints, and expensive operations. Send 100 rapid requests to the login endpoint. If none get blocked, the API has no rate limiting on authentication, which enables credential stuffing at scale. Try bypassing rate limits by rotating IP addresses through proxies, adding X-Forwarded-For headers with different values, or switching between API versions that may have different limit configurations.

Some APIs enforce limits per API key but not per IP. If an attacker can obtain a valid API key, they can hammer the endpoint from multiple connections without triggering the limit. Test this by exhausting the quota on one key, then switching to another and confirming the block is per-key, not global.

Step 6: Input fuzzing and response validation. Fuzzing sends unexpected data to every parameter and observes how the API responds. Use tools like Burp Intruder or ffuf to send payloads from lists like SecLists. Watch for server errors (500 status codes), stack traces in responses, timing differences between requests, and differences in response length that indicate the backend processed the input differently than expected.

Response validation is about what the API returns, not what it accepts. Check for excessive data exposure: does the /users/me endpoint return the full user object including password hash fields, internal IDs, or permission flags that the frontend never displays? Does the error response for a failed login reveal whether the username exists ("user not found" versus "incorrect password")? Does the API include debug information, stack traces, or internal paths in error responses? Each of these is an information disclosure issue that helps an attacker map the system.

Document every finding with the request, response, and reproduction steps. A finding without a clear reproduction path is not actionable. For organizations that need formal documentation, this methodology maps directly to the output format expected in a VAPT assessment report.

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.