A primer on API testing

APIs are the glue that connect components and services in modern, distributed software systems. As a tester, it’s therefore important to know what and how to test at the API level, especially when their testing is focused on finding potential problems around the integration points between different components and services.

Testing APIs and testing components through APIs isn’t very different from testing applications through the graphical user interface, but despite that, many testing efforts at the API level still come short of being effective. To give you a nudge in the right direction, let’s look at some tips and tricks that can help you do better in your API testing.

Start with confirming that your API works as expected …

Before we start looking for problems with our APIs, it’s a good idea to confirm that the API works according to the specifications. Here are some things you might want to test for in this stage:

• Does an HTTP GET to /orders/123 return the expected HTTP 200 status code and the details for order 123?
• Does an HTTP POST to /orders with the specified request data in the payload or in query parameters create the order as expected?
• Does an HTTP DELETE to /orders/456 delete order 456, and only order 456?

Tests like the above are typically what’s covered by most ‘introduction to API testing’ tutorials and courses, and they are a great start. These tests also form a good target for automation, enabling you to verify that the behaviour of your APIs meets the specifications as you further develop the APIs and the systems behind them.

… but don’t stop there!

However, merely confirming that something works, or rather that it can work, is not enough. As testers, it’s important to go beyond this verification in our API testing efforts, in order to find deeper, more elusive problems. Our APIs are the connection between different components or systems and, as such, responsible for the reliable exchange of data between them. We want to make sure that they are robust and can handle not just what’s expected according to the specifications, but that they can also handle unexpected inputs in an appropriate manner, for example:

• Assuming that order IDs are numerical, what happens when you use an invalid order ID in an HTTP GET, for example to /orders/$$abc$$?
• What happens when you omit the required customerId field when creating a new order through an HTTP POST?
• What happens when you try and place an order for an item that is out of stock?

The way your API responds to these inputs can tell you a lot about their robustness and resiliency to unexpected inputs. Of course, the above is far from a complete list. For instance, we haven’t even touched on the topic of API load testing yet, or in other words, the way the API responds to thousands of orders placed in a short amount of time, with or without the required stock to fulfill these orders.

As you can see, there’s a lot to explore around the behaviour of APIs, and a healthy dose of creativity and curiosity goes a long way when you’re testing your APIs. There’s one area, however, that I want to pay special attention to here.

Are you sure your API is secure?

The reason APIs exist is to enable software components and systems to perform CRUD (Create, Read, Update, Delete) operations on data. An estimated 83% of all data moving around online is transferred via an API these days. This makes APIs an exceptionally attractive attack vector for people looking to obtain unauthorized access to that data.

Therefore, is it incredibly important that the API you’re building is secure enough to withstand potential attacks from people with malicious intent. As testers involved in testing APIs, we should be able to perform a decent measure of security testing on APIs.

The good news is, this doesn’t necessarily required deep, specific technical knowledge or exotic tools. Using common API testing tools like Postman and a healthy dose of creativity and curiosity, every tester can obtain valuable information about the security of the API they’re working with:

• Authenticating yourself as user Adam, can you retrieve details for order 456, belonging to user Barbara, for example using an HTTP GET to /orders/456? - If you are, this is an example of BOLA or Broken Object Level Authorization, the most common API security vulnerability according to the 2023 OWASP API security top 10.
• Authenticating yourself as user Adam, can you adjust the outstanding payment for your order 123 to 0, effectively enabling you to order items without paying for them, for example using an HTTP PUT or PATCH to /orders/123? - If you are, that’s an example of BFLA or Broken Function Level Authorization, number 5 on the same list.
• Can you abuse the API flow of a web shop selling limited edition items, such as sought after concert tickets, to effectively scalp all the tickets and resell them at a much higher price? - This is an example of Unrestricted Access to Sensitive Business Flows, number 6 on the OWASP list.

As you can see, everybody with a foundational understanding of APIs and of testing has the skill set to get started with API security testing, and it is an area that I highly recommend you explore a bit further.

Want to learn more?

Speaking of exploring a bit further, if you would like to learn more about exploratory APi testing, I highly recommend this course on Test Automation University by Amber Race.

If you’re interested in API security testing specifically, APISec University has a number of high-quality free video courses.

And if you learn better through hands-on, live workshops, I’m offering a number of corporate workshops and training courses on different topics related to API testing, including API security testing.