APIs have become the backbone of modern applications. Web applications, mobile apps, SaaS platforms, cloud services, payment systems, microservices, and third-party integrations all depend on APIs to exchange data and perform business operations.

That makes API security testing an essential part of modern penetration testing. An API may expose hundreds of endpoints, multiple authentication mechanisms, sensitive objects, administrative functions, and business workflows. A single authorization mistake can allow one user to access another user’s account, modify sensitive information, or perform an operation intended only for administrators.

API security has also become more complicated as organizations move toward cloud-native architectures and distributed applications. In 2026, NIST continues to emphasize API security across the development and runtime lifecycle, including specific guidance for RESTful APIs. NIST’s updated API protection guidance also recommends a risk-based approach to API controls and highlights the importance of securing APIs under zero-trust principles.

The OWASP API Security Top 10 remains one of the most useful references for security professionals. Its 2023 edition places particular emphasis on authorization problems, sensitive business flows, SSRF, API inventory, and unsafe consumption of APIs.

This API security testing checklist provides a practical methodology that penetration testers, developers, security engineers, and organizations can use to assess API security systematically.

What Is API Security Testing?

API security testing is the process of evaluating an API for vulnerabilities that could allow unauthorized access, data exposure, privilege escalation, manipulation of business operations, denial of service, or compromise of connected systems.

Unlike traditional web application testing, API testing focuses heavily on the application’s endpoints, HTTP methods, parameters, authentication mechanisms, authorization logic, API schemas, object relationships, and backend behavior.

For example, consider:

GET /api/v1/users/1001/profile

A basic test might confirm that the endpoint works for user 1001.

A proper security test asks a much more important question:

What happens if an authenticated user changes 1001 to 1002?

If the server returns another user’s private profile without verifying ownership, the application may have a Broken Object Level Authorization vulnerability.

This is why API testing cannot rely only on automated scanners. The tester needs to understand how the application is supposed to behave.

Why API Security Testing Is Important

APIs frequently sit between the user and sensitive backend functionality.

An API might provide access to:

• Personal information
• Payment data
• Customer records
• Authentication functions
• Password reset functionality
• Internal applications
• Administrative operations
• Cloud resources
• Database records
• Business transactions
• Third-party integrations

A vulnerable API can therefore become a direct path to sensitive information or critical business functionality.

OWASP’s API Security Top 10 2023 identifies authorization as a particularly important challenge, with several of its highest-ranked risks involving access control.

NIST’s current API guidance similarly treats API protection as a lifecycle problem rather than something that should be added only after deployment.

Organizations should therefore test APIs during development, before production deployment, and periodically after deployment.

API Security Testing Methodology

A good API penetration test should follow a structured process.

A practical workflow is:

Reconnaissance
      ↓
API Discovery
      ↓
Authentication Testing
      ↓
Authorization Testing
      ↓
Input Validation
      ↓
Business Logic Testing
      ↓
Configuration Testing
      ↓
Rate-Limit Testing
      ↓
API Inventory Testing
      ↓
Third-Party Integration Testing
      ↓
Reporting & Remediation

The goal is not simply to find as many vulnerabilities as possible. The goal is to understand how the API behaves and determine whether an attacker can abuse that behavior.

API Security Testing Checklist

1. API Reconnaissance and Discovery

Before attacking an API, identify its attack surface.

Start by collecting API documentation, endpoint information, authentication requirements, supported HTTP methods, parameters, schemas, and API versions.

Look for:

• /api/
• /api/v1/
• /api/v2/
• /rest/
• /graphql
• /swagger
• /swagger.json
• /openapi.json
• /docs
• /api-docs
• /health
• /admin
• /internal
• /debug

Also inspect JavaScript files used by web applications. Client-side code often contains API endpoints that are not clearly documented.

API Discovery Checklist

• Identify all known API domains and subdomains.
• Identify API versions.
• Review OpenAPI or Swagger documentation.
• Search JavaScript files for hidden endpoints.
• Identify undocumented parameters.
• Identify deprecated endpoints.
• Identify administrative endpoints.
• Identify internal API endpoints.
• Identify GraphQL or gRPC services.
• Identify API gateway and reverse-proxy behavior.
• Check whether API documentation is publicly accessible.

Do not assume that the documented API is the complete attack surface.

A production application may still expose an older /v1/ endpoint after introducing /v2/.

2. Authentication Testing

Authentication determines who the API believes the caller is.

Weak authentication can make otherwise secure endpoints dangerous.

Test all authentication mechanisms, including:

• Bearer tokens
• JWT
• API keys
• OAuth 2.0
• Session cookies
• Basic authentication
• Mutual TLS
• Custom authentication headers

Authentication Checklist

• Test missing authentication.
• Test invalid tokens.
• Test expired tokens.
• Test revoked tokens.
• Test malformed tokens.
• Test token reuse.
• Test authentication bypass.
• Test weak password policies where applicable.
• Test account enumeration.
• Test password reset functionality.
• Test session invalidation after logout.
• Test whether sensitive operations require reauthentication.
• Test whether authentication can be bypassed by changing HTTP methods or endpoints.

For JWT-based authentication, inspect the token structure and verify that the server correctly validates the signature, issuer, audience, expiration, and other relevant claims.

Do not treat a valid-looking JWT as proof that its contents should automatically be trusted.

3. Authorization Testing

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

This distinction is critical.

Authorization vulnerabilities are among the most important API security issues identified by OWASP.

Broken Object Level Authorization

Consider:

GET /api/orders/5001

A user should normally be able to retrieve only their own order.

During an authorized penetration test, compare behavior using two test accounts:

User A → /api/orders/5001 → Allowed
User B → /api/orders/5001 → Should be denied

If User B can access User A’s order, the API may be vulnerable to BOLA.

Authorization Checklist

• Test horizontal privilege escalation.
• Test vertical privilege escalation.
• Test cross-user object access.
• Test access to administrative endpoints.
• Test authorization on every HTTP method.
• Test authorization after changing object IDs.
• Test authorization using different user roles.
• Test authorization on nested resources.
• Test authorization on hidden endpoints.
• Test authorization after changing request parameters.

Do not test only GET requests.

An endpoint may correctly protect:

GET /api/users/1001

while failing to protect:

PUT /api/users/1001

or:

DELETE /api/users/1001

4. Object Property Authorization

APIs often return or accept many object properties.

For example:

{
  "name": "John",
  "email": "john@example.com",
  "role": "user",
  "isAdmin": false
}

The security problem occurs when the server allows a normal user to modify properties they should not control.

Test for:

• Mass assignment.
• Hidden administrative fields.
• Role modification.
• Account ownership modification.
• Price manipulation.
• Status modification.
• Internal identifiers.
• Sensitive response fields.

For example, if a normal account can submit:

{
  "name": "John",
  "isAdmin": true
}

and the server accepts it, the impact can be severe.

The server should explicitly define which fields a user is allowed to modify.

5. HTTP Method Testing

Never assume that an endpoint supports only the method shown in the documentation.

Test appropriate methods such as:

GET
POST
PUT
PATCH
DELETE
OPTIONS
HEAD

Checklist

• Test unauthorized methods.
• Test method-based authorization.
• Compare GET and POST behavior.
• Compare PUT and PATCH behavior.
• Test DELETE authorization.
• Check unexpected OPTIONS behavior.
• Check method override mechanisms.
• Verify that unsupported methods return appropriate responses.

A common mistake is securing one HTTP method while leaving another method exposed.

6. Input Validation Testing

Every parameter entering an API should be treated as untrusted input.

Test:

• Query parameters
• Path parameters
• JSON body fields
• Form parameters
• HTTP headers
• Cookies
• File uploads
• GraphQL arguments

Look for:

• SQL injection
• NoSQL injection
• Command injection
• LDAP injection
• XML injection
• Template injection
• Path traversal
• Cross-site scripting where applicable
• Server-side expression injection

Example

Instead of testing only:

{
  "username": "john"
}

evaluate how the application handles unexpected types, lengths, formats, and values.

For example:

{
  "username": null
}

or:

{
  "username": 12345
}

or excessively long input.

The objective is to determine whether unexpected input causes information disclosure, application errors, authorization bypass, or backend injection.

7. Rate Limiting and Resource Consumption

APIs can be abused by sending large numbers of requests or expensive requests.

Test endpoints involved in:

• Login
• OTP verification
• Password reset
• Registration
• Search
• File processing
• Report generation
• Export functionality
• Payment operations
• Resource-intensive queries

Checklist

• Check login rate limits.
• Check OTP rate limits.
• Check password-reset rate limits.
• Test per-user limits.
• Test per-IP limits.
• Test token-based limits.
• Test expensive API operations.
• Test large request bodies.
• Test large pagination values.
• Test excessive page sizes.
• Check whether rate limits can be bypassed through alternate endpoints.

Do not assume that a simple 429 Too Many Requests response automatically means rate limiting is secure.

Determine whether the control can actually prevent abuse.

8. Business Logic Testing

Some of the most serious API vulnerabilities are not traditional technical injection vulnerabilities.

They involve abusing legitimate functionality in an unintended way.

Consider an e-commerce API:

POST /api/cart/apply-discount

The endpoint may correctly authenticate the user and validate the request.

However, a tester might discover that a discount intended to be used once can be repeatedly applied.

That is a business logic vulnerability.

Business Logic Checklist

• Test repeated transactions.
• Test transaction ordering.
• Test negative quantities.
• Test unexpected price values.
• Test coupon reuse.
• Test account creation abuse.
• Test referral abuse.
• Test workflow bypass.
• Test skipped verification steps.
• Test race conditions.
• Test sensitive operations without required prerequisites.

OWASP added Unrestricted Access to Sensitive Business Flows to its 2023 API Top 10, reflecting the importance of protecting workflows such as automated account creation and other abuse-prone operations.

9. SSRF Testing

Server-Side Request Forgery occurs when an API allows an attacker to influence requests made by the server.

Common examples include:

POST /api/webhook
POST /api/import
POST /api/fetch
POST /api/image

If an endpoint accepts a URL, determine whether the backend validates the destination properly.

SSRF Checklist

• Identify URL-based parameters.
• Test whether external URLs can be requested.
• Test redirect handling.
• Check allowlist implementation.
• Check DNS resolution behavior.
• Check IPv4 and IPv6 handling.
• Test URL parser inconsistencies.
• Check whether internal destinations are blocked.
• Check cloud metadata protection.
• Check webhook security.

SSRF was explicitly added to the OWASP API Security Top 10 in 2023 because API-driven features such as webhooks and cloud control interfaces can increase its impact.

Only perform SSRF testing against systems you are authorized to assess.

10. Security Misconfiguration

A secure application can still become vulnerable because of incorrect configuration.

Check:

• Debug mode.
• Verbose error messages.
• Stack traces.
• Exposed Swagger documentation.
• Default credentials.
• Missing security headers where relevant.
• CORS configuration.
• TLS configuration.
• Unnecessary HTTP methods.
• Exposed administrative interfaces.
• Directory listing.
• Internal hostnames.
• Version disclosure.

A response such as:

DatabaseException:
Connection failed to db-prod-03.internal

may expose information that helps an attacker understand the internal architecture.

Error responses should provide useful information to legitimate clients without revealing unnecessary internal details.

11. CORS Testing

Cross-Origin Resource Sharing controls how browsers allow web pages to interact with APIs hosted on different origins.

Review:

Access-Control-Allow-Origin
Access-Control-Allow-Credentials
Access-Control-Allow-Methods
Access-Control-Allow-Headers

Checklist

• Test allowed origins.
• Test unauthorized origins.
• Test wildcard origins.
• Test credentialed requests.
• Test origin reflection.
• Test null origin behavior.
• Test preflight requests.
• Verify sensitive APIs do not expose overly broad CORS policies.

CORS is primarily a browser security mechanism. A permissive CORS policy does not automatically mean the API is directly exploitable from every client, so evaluate it together with the authentication model and browser behavior.

12. Sensitive Data Exposure

Review API responses carefully.

Look for:

• Password hashes
• API keys
• Access tokens
• Refresh tokens
• Internal IDs
• Database identifiers
• Personal information
• Payment information
• Internal hostnames
• Debug information
• Authorization data

Compare responses between normal users and privileged users.

An API should return only the information required by the client.

For example, if a mobile application needs:

{
  "name": "John",
  "profileImage": "/images/john.jpg"
}

there is little reason for the endpoint to return internal account metadata, password-reset information, or administrative flags.

13. API Version and Inventory Testing

API inventory is often overlooked.

Organizations may have:

/api/v1/
/api/v2/
/api/v3/

with different security controls.

The oldest version may contain vulnerabilities that were fixed in the newest version.

Checklist

• Identify all API versions.
• Test deprecated endpoints.
• Identify undocumented endpoints.
• Search DNS and subdomains.
• Search application source code.
• Review mobile application traffic.
• Check staging environments.
• Check development environments.
• Check old documentation.
• Identify shadow APIs.
• Verify retired APIs are actually disabled.

OWASP lists Improper Inventory Management as API9:2023, highlighting the security risk created when organizations do not maintain an accurate view of their API estate.

14. API Documentation Testing

Swagger and OpenAPI documentation can be extremely useful during penetration testing.

But publicly exposed documentation can also reveal:

• Internal endpoints
• Parameter names
• Authentication mechanisms
• Object models
• Administrative functions
• Deprecated APIs
• Internal hostnames

Check whether documentation is accessible without authentication.

If it must be public, verify that it does not expose unnecessary sensitive implementation details.

15. File Upload Testing

If the API accepts files, test:

• File type validation.
• MIME validation.
• File extension validation.
• File size restrictions.
• Filename handling.
• Path traversal.
• Archive extraction.
• Image processing.
• Metadata handling.
• Storage permissions.
• Direct file access.
• Malware scanning controls.

Do not rely only on the file extension.

An API should validate uploaded content using multiple controls appropriate to the application’s use case.

16. GraphQL API Testing

GraphQL introduces a different testing model because clients can construct queries against a schema.

Test:

• Introspection exposure.
• Authorization at resolver level.
• Excessive query depth.
• Query complexity.
• Alias abuse.
• Nested object authorization.
• Sensitive fields.
• Mutation authorization.
• Error disclosure.
• Rate limiting.

A GraphQL endpoint may expose only one URL while providing access to a large number of operations.

Therefore, testing only the endpoint itself is not enough. The schema and resolver behavior must also be examined.

17. Third-Party API Testing

Modern applications rarely operate in isolation.

An application may communicate with:

• Payment providers
• Identity providers
• Cloud services
• Email platforms
• Analytics services
• Shipping providers
• CRM systems
• SaaS applications

Test how the application handles responses from external services.

Check:

• Third-party authentication.
• API key storage.
• TLS validation.
• Response validation.
• Redirect handling.
• Error handling.
• Trust boundaries.
• Webhook authentication.
• Signature verification.
• Sensitive data sent to third parties.

OWASP’s API10 category, Unsafe Consumption of APIs, specifically addresses risks created when applications trust data received from other APIs without sufficient validation.

18. Logging and Monitoring

Security testing should also examine whether suspicious API activity can be detected.

Verify that security-relevant events are logged, such as:

• Authentication failures
• Privilege changes
• Password resets
• Administrative operations
• Excessive requests
• Suspicious object access
• Token failures
• Sensitive data access

At the same time, logs should not contain secrets such as passwords, access tokens, or unnecessary personal information.

A vulnerability that cannot be detected can remain exploitable for much longer.

API Security Testing Tools

Different stages of an API assessment require different tools.

Burp Suite

Burp Suite is widely used for intercepting and modifying HTTP requests and responses.

It is particularly useful for:

• Parameter manipulation
• Authorization testing
• Request replay
• Authentication testing
• Session analysis
• Manual API testing

OWASP API Security Testing Framework

OWASP also maintains an API Security Testing Framework designed specifically around API security assessment. The current project describes automated coverage for the OWASP API Security Top 10 2023 and additional areas such as GraphQL, gRPC, mutual TLS, and injection testing.

OWASP API Security Testing Framework

Postman

Postman can be useful for organizing API requests, environments, authentication flows, and regression tests.

Security testers can use it to build repeatable test collections and compare responses across different user roles.

cURL

For quick testing, cURL remains useful because it provides direct control over HTTP requests.

For example:

curl -i https://target.example/api/profile

A security tester can then add the appropriate authorization header and compare responses across controlled test accounts.

API Security Labs

Practical testing becomes much easier when you can experiment against intentionally vulnerable applications.

For hands-on practice, cyber security labs can help learners develop API testing skills in a controlled environment.

API Security Testing Checklist for Penetration Testers

Use this condensed checklist during an assessment.

Reconnaissance

• Identify API domains.
• Identify API versions.
• Discover documented endpoints.
• Discover undocumented endpoints.
• Review OpenAPI/Swagger files.
• Identify GraphQL/gRPC services.
• Identify administrative endpoints.

Authentication

• Test missing authentication.
• Test invalid authentication.
• Test expired tokens.
• Test revoked tokens.
• Test session invalidation.
• Test password reset.
• Test token validation.
• Test authentication bypass.

Authorization

• Test BOLA.
• Test BFLA.
• Test horizontal privilege escalation.
• Test vertical privilege escalation.
• Test object property authorization.
• Test nested resources.
• Test every HTTP method.

Input Validation

• Test path parameters.
• Test query parameters.
• Test JSON fields.
• Test headers.
• Test file uploads.
• Test injection vulnerabilities.
• Test unexpected data types.
• Test oversized input.

Business Logic

• Test workflow bypass.
• Test repeated transactions.
• Test race conditions.
• Test coupon abuse.
• Test price manipulation.
• Test account creation abuse.
• Test sensitive business flows.

Configuration

• Check CORS.
• Check TLS.
• Check error handling.
• Check debug mode.
• Check security headers.
• Check API documentation.
• Check default configurations.

Infrastructure

• Test rate limiting.
• Test resource consumption.
• Test SSRF.
• Test exposed internal services.
• Test deprecated API versions.
• Test shadow APIs.

Data Protection

• Check sensitive responses.
• Check token exposure.
• Check API key exposure.
• Check excessive data returned.
• Check logging of sensitive information.

Common API Security Testing Mistakes

Testing Only the Happy Path

A common mistake is testing:

Valid user
+
Valid token
+
Valid request
=
Expected response

Security testing should focus on what happens when those assumptions change.

Try different users, roles, object IDs, methods, parameters, and request sequences.

Relying Entirely on Automated Scanners

Automated tools are valuable, but business logic and authorization vulnerabilities often require human reasoning.

A scanner may identify an endpoint.

It may not understand whether:

User A should be allowed to modify Order B

That requires application context.

Ignoring API Versions

Old endpoints can remain accessible long after developers stop maintaining them.

Always check previous versions.

Testing Only GET Requests

Authorization and input validation can behave differently across:

GET
POST
PUT
PATCH
DELETE

Test the entire API operation set.

Ignoring Business Logic

An API can pass authentication and authorization checks and still allow users to abuse a legitimate workflow.

Business logic testing should therefore be part of every serious API assessment.

How to Improve API Security

Security should not stop when the penetration test ends.

Organizations should:

1. Maintain an accurate API inventory.
2. Apply authorization checks consistently.
3. Use strong authentication.
4. Validate all input.
5. Minimize returned data.
6. Apply appropriate rate limits.
7. Protect sensitive business flows.
8. Secure third-party integrations.
9. Monitor API activity.
10. Remove deprecated endpoints.
11. Test APIs continuously.
12. Include security testing in CI/CD.

NIST’s current guidance emphasizes API security across the development and runtime lifecycle and recommends selecting controls according to organizational risk and deployment conditions.

For teams building practical security skills, cyber security training can complement technical API testing with broader penetration-testing knowledge.

API Security Testing Career Opportunities

API security testing is a valuable skill for penetration testers because modern applications increasingly depend on APIs.

Professionals who understand API testing can work toward roles such as:

• Junior Penetration Tester
• API Security Tester
• Web Application Security Tester
• Application Security Engineer
• Security Consultant
• VAPT Analyst
• Bug Bounty Hunter
• Red Team Operator

The most valuable skill is not simply knowing how to send requests.

A strong API penetration tester understands authentication, authorization, HTTP, application architecture, databases, cloud environments, business logic, and secure development practices.

Practical experience is especially important. Working with intentionally vulnerable applications and real-world testing scenarios helps turn theoretical knowledge into repeatable methodology.

Useful API Security References

For further study, security professionals should regularly consult authoritative resources.

• OWASP API Security Project — API-specific vulnerabilities and defensive guidance.
• OWASP API Security Top 10 — Current OWASP API Top 10 edition.
• NIST API Protection Guidance — API protection guidance for cloud-native systems.
• NIST RESTful Web API Guidance — Specific guidance for RESTful APIs.
• PentestHint — Additional penetration-testing and cybersecurity resources.

FAQ

What is API security testing?

API security testing is the process of assessing APIs for vulnerabilities involving authentication, authorization, input validation, business logic, configuration, data exposure, resource consumption, and other security weaknesses.

What should I test first in an API?

Start with API discovery and authentication, then move to authorization. BOLA, privilege escalation, and object-level access control should receive particular attention because authorization failures can expose sensitive data or functionality.

What is BOLA in API security?

BOLA stands for Broken Object Level Authorization. It occurs when an API fails to verify whether the authenticated user is authorized to access a specific object.

For example, changing:

/api/orders/1001

to:

/api/orders/1002

and receiving another user’s order may indicate a BOLA vulnerability.

Is API security testing different from web application penetration testing?

Yes, although there is significant overlap. API testing focuses heavily on endpoint behavior, object authorization, API schemas, HTTP methods, authentication tokens, data serialization, business workflows, and machine-to-machine communication.

Which tools are useful for API security testing?

Common tools include Burp Suite, Postman, cURL, API documentation tools, OpenAPI-based testing tools, and specialized API security testing frameworks. Manual testing remains important for authorization and business logic vulnerabilities.

How do I test JWT security?

Review how the application validates JWT signatures, expiration, issuer, audience, token type, and other relevant claims. Also test token lifecycle behavior such as expiration, revocation, logout, and privilege changes.

Do not assume that modifying a JWT locally is automatically a vulnerability. The important question is whether the server incorrectly accepts a token that should be rejected.

Why is API inventory important?

Organizations often have multiple API versions, undocumented endpoints, staging environments, deprecated services, and third-party integrations. An incomplete inventory can leave vulnerable endpoints exposed without anyone realizing they are still accessible.

Can automated tools find all API vulnerabilities?

No. Automated tools are useful for discovery and repeatable checks, but they cannot reliably understand every authorization relationship, business workflow, or application-specific security requirement. Manual analysis is essential for a thorough API security assessment.

Conclusion

API security testing is no longer an optional addition to a penetration test. APIs are responsible for connecting modern applications to databases, cloud services, mobile clients, payment systems, identity providers, and other business-critical platforms.

A strong assessment starts with complete API discovery and then moves through authentication, authorization, input validation, business logic, resource consumption, SSRF, configuration, inventory, and third-party integrations.

The most important lesson is to test how the API behaves when normal assumptions are broken. Change the user. Change the object ID. Change the role. Change the HTTP method. Modify parameters. Repeat sensitive operations. Examine unexpected responses.

Use the OWASP API Security Top 10 as a foundation, complement it with current NIST guidance, and validate findings manually wherever application context matters. OWASP’s current API security resources and NIST’s 2026 API guidance provide useful references for building a structured testing program.

For organizations looking to strengthen their application security posture, VAPT services can form part of a broader security assessment strategy.

For security professionals, the best way to improve is to combine theory with hands-on testing. Build your own methodology, practice against vulnerable APIs, document every finding clearly, and keep your knowledge aligned with evolving API architectures and security standards.

API security is ultimately about one question:

Can the API be trusted to perform exactly what the caller is authorized to do—and nothing more?

That is the question every API security test should answer.