API Testing

APIs (Application Programming Interfaces) enable software systems and applications to communicate and share data. API testing is important as vulnerabilities in APIs may undermine core aspects of a website’s confidentiality, integrity, and availability.

All dynamic websites are composed of APIs, so classic web vulnerabilities like SQL injection could be classed as API testing.

API recon

To start API testing, you first need to find out as much information about the API as possible, you should identify API endpoints. These are locations where an API receives requests about a specific resource on its server.

For example, consider the following GET request: GET /api/books HTTP/1.1 Host: example.com

The API endpoint for this request is /api/books. This results in an interaction with the API to retrieve a list of books from a library.

Once you have identified the endpoints, you need to determine how to interact with them. This enables you to construct valid HTTP requests to test the API. For example, you should find out information about the following:

1. The input data the API processes, including both compulsory and optional parameters.
2. The types of requests the API accepts, including supported HTTP methods and media formats.
3. Rate limits and authentication mechanisms.

you can use Burp Scanner to crawl the API. You can also browse applications manually using Burp’s browser.

If you identify an endpoint for a resource, make sure to investigate the base path. For example, if you identify the resource endpoint /api/swagger/v1/users/123, then you should investigate the following paths:

• /api/swagger/v1
• /api/swagger
• /api

Identifying API endpoints

look for patterns that suggest API endpoints in the URL structure, such as /api/. Also look out for JavaScript files. These can contain references to API endpoints that you haven't triggered directly via the web browser. Burp Scanner automatically extracts some endpoints during crawls, but for a more heavyweight extraction, use the JS Link Finder BApp. You can also manually review JavaScript files in Burp.

Identifying supported HTTP methods

The HTTP method specifies the action to be performed on a resource. For example:

• GET - Retrieves data from a resource.
• PATCH - Applies partial changes to a resource.
• OPTIONS - Retrieves information on the types of request methods that can be used on a resource.

An API endpoint may support different HTTP methods. It’s therefore important to test all potential methods when you’re investigating API endpoints. This may enable you to identify additional endpoint functionality, opening up more attack surface.

For example, the endpoint /api/tasks may support the following methods:

• GET /api/tasks - Retrieves a list of tasks.
• POST /api/tasks - Creates a new task.
• DELETE /api/tasks/1 - Delete a task.

Identifying supported content types

API endpoints often expect data in a specific format. They may therefore behave differently depending on the content type of the data provided in a request. Changing the content type may enable you to:

• Trigger errors that disclose useful information.
• Bypass flawed defenses.
• Take advantage of differences in processing logic. For example, an API may be secure when handling JSON data but susceptible to injection attacks when dealing with XML.

To change the content type, modify the Content-Type header, then reformat the request body accordingly. You can use the Content type converter Burp App to automatically convert data submitted within requests between XML and JSON.

Using Intruder to find hidden endpoints

Once you have identified some initial API endpoints, you can use Intruder to uncover hidden endpoints. For example, consider a scenario where you have identified the following API endpoint for updating user information:

PUT /api/user/update

To identify hidden endpoints, you could use Burp Intruder to find other resources with the same structure. For example, you could add a payload to the /update position of the path with a list of other common functions, such as delete and add.

When looking for hidden endpoints, use wordlists based on common API naming conventions and industry terms. Make sure you also include terms that are relevant to the application, based on your initial recon.

Preventing vulnerabilities in APIs

When designing APIs, make sure that security is a consideration from the beginning. In particular, make sure that you:

• Secure your documentation if you don’t intend your API to be publicly accessible.
• Ensure your documentation is kept up to date so that legitimate testers have full visibility of the API’s attack surface.
• Apply an allow list of permitted HTTP methods.
• Validate that the content type is expected for each request or response.
• Use generic error messages to avoid giving away information that may be useful for an attacker.
• Use protective measures on all versions of your API, not just the current production version.

Conclusion

API testing is a critical part of the software development lifecycle, ensuring that your applications communicate correctly and reliably. By implementing comprehensive testing strategies, from functional and performance testing to security testing, you can identify and fix potential issues early, leading to more robust and user-friendly software.

Ready to take your API testing to the next level? Share your favorite API testing tools or tips in the comments below! And don’t forget to follow me for more insights and best practices on software testing and development.

Thank you GitHub | Instagram | Twitter