Skip to content
Close
Login
Login

Best Practices for REST API Testing

A good concept for REST API testing is a prerequisite for stable high-class services.

Learn How to Build REST APIs Your Business Can Rely on

There are many different ways to test REST APIs. To help you find the solution that is best for your project(s), we have summarized all relevant information about REST API testing for you to check out below.

What to Expect on This Page

The Challenges of REST API Testing

Delivering high quality REST APIs is a challenging task, as they are highly complex: Some code is difficult to reach, endpoints can consume countless parameter combinations, and constantly communicate with a vast number of other systems. Looking for any type of weakness putting stability at risk or even opening doors for attackers in REST APIs manually is like looking for a needle in a haystack. To deal with the complexity of REST APIs, dev teams test APIs with automated methods. Below, you can find an overview of the top 6 challenges of REST API testing.

1. Initial Documentation of a REST API

As presented below, REST APIs consist of various different parameters such as request method, request URI and query parameter - just to name a few. These parameters can take up countless combinations that have to be tested, as specific parameter combinations can lead to erroneous program states. Documentation like e.g. “OpenAPI” may not even reveal the existence of some parameters.

Query Parameter

 

2. Validating REST API Parameters

Validating REST API parameters is highly challenging. If they are not validated properly, issues such as wrong string/data types and parameter data outside the predefined value range can come up.

3. Evolving the API and Maintaining the Documentation

The documentation is the written contract of the API and specifies how REST APIs handle requests and responses. The challenge in maintaining the documentation is that whenever new parameters are added, parameter limits change or responses change, this has to be reflected in the documentation. Of course, not breaking an existing contract without properly handling it by delivering a breaking change is crucial.

4. Testing REST API Call Sequences (Stateful testing)

Testers must frequently ensure that REST API calls are called in the correct order to test in depth. Even incorrect handling of the order and concurrency issues need to be taken care of as they are frequently found in REST APIs.

5. REST API Testing Set-Up

Setting up automated testing cycles is the part of REST API testing that requires the most manual effort. Especially for large projects, enterprise testing platforms not owned by the developers writing the code are costly to set up and maintain. Testing as close as possible to the time the code is written, will help you to reduce late findings and costly set ups.

6. Error Reporting for REST APIs

Testing the API just from outside without knowledge of the code, error reporting for REST APIs is tricky, as we frequently see a state involved and reproducing might be tricky. The best way to monitor a REST API and report issues is with coverage-guided testing approaches. These approaches ensure knowing each line of code, track where exactly issues happen and even collect coverage information in one go and make reproducing any issue a matter of minutes.

How to Automate Testing for REST APIs

Due to the complex structure of REST APIs, automated testing is one of the most effective ways to ensure smooth, reliable and secure operation. But not all automated testing approaches are equally effective. The fastest way to implement software test automation would be any testing of the final API running on a server with API testing tools, such as Burp or OWASP ZAP, potentially enhanced with some additional system tests. In this setup, typically other, not the teams writing the code take over responsibility for the quality assurance of the API. 

Although these approaches are somewhat automated, they leave plenty of room for improvement, as they still require testers to have prior knowledge about the system under test in order to be effective and to maintain separate tests. These tests are great to test APIs from an attacker's perspective. But they do not make use of the biggest advantage developers of an API have: Knowledge of the source code. They generate test inputs randomly, from static corpora, from OpenAPI imports, or based on heuristics. However, such inputs often fail to reach API specific complex issues and edge cases, since they do not take code coverage into account. For example, such a testing tool would take the API request from above and try out countless different parameter settings in hopes of identifying a request that breaks something.

Automated testing from inside the code is far more effective at finding buggy REST API requests: Since they use information about the source code, these approaches can automatically exclude irrelevant parameter settings from the corpus. Through information about code coverage, they can find crashing REST API requests much faster and much more accurately. This automation also enables better reporting by providing code-coverage visibility. The advantages of this approach are especially useful to test vast microservice environments that are connected through APIs, and projects that are expanding in size.

Testing Before Deploying vs After Deploying

While there are several different ways to test a REST API, one of the most helpful distinctions is to consider testing before and after deploying a service. In this case, this could mean deploying a REST API to a development environment or developer’s workstation, deploying to an internal-only test or staging environment for testing by multiple individuals and teams, or deploying to production to some or all end users. Testing before deployment starts with unit testing, and testing the “happy case”, the underlying business logic of a REST API. Testing against all potential negative cases is highly important at a single API level to keep the number of potential combinations still limited. “Happy case” testing and negative testing can be done in full isolation and with spinning up next related services in a local setup.

Testing after deployment faces some risks and comes with significantly increased cost. It is required but should be replaced with before deployment tests wherever possible. When done right, both testing before and after deployment is critical to ensure a high-quality API.

Testing before deployment is effective for testing business logic and contracts of the service. Functional unit testing is an excellent approach here, since the developer has full control over the source code and can create unit test cases based on the business requirements. Finding any type of bug based on unit testing and integrated end point testing before deployment greatly reduces the risk of such defects affecting end users or even other developer teams that may use the API service. 

Adding edge case or negative testing allows to cover for all unexpected inputs, all that could potentially go wrong on smallest service levels. This ensures robust and reliable systems building on them.

Testing pre-deployment has the benefit of significantly faster execution time, since network connections are mocked out completely. Network overhead is typically the bottle neck when testing APIs. 

Testing the API endpoints before deployment also has the benefit of much faster turnaround times and less management overhead. Fuzz testing is one approach invented to find major software flaws in both the business logic layer and REST API service layer. Using fuzzing to automatically cover all edge cases a developer did not think about and is an excellent way for application developers to “shift left”, take over full responsibility for the API while using familiar test frameworks, tools and processes. It will reduce the number of manually written tests, reduce the time thinking of test cases and even maintain tests continuously.

Fuzz Testing for REST APIs

The most efficient way to implement automated API testing is with feedback-based fuzzing. Feedback-based fuzz testing is a form of data-driven testing, during which code instrumentation is used to measure the test progress within individual microservices and APIs. Through this instrumentation, the fuzzer collects information about what paths the test inputs took in the code, which it then uses to create further inputs that traverse even more code paths. Modern fuzzing solutions can be customized to scan for specific bug classes and to remove blockers. Since this technology can be integrated into any build system, it enables developers to continuously test APIs for all types of bugs caused by unexpected inputs. 

As mentioned above, fuzzing a service pre-deployment and locally on a developer machine like any unit test, is a great approach for testing of a REST API because of the reduced latency of local testing. This allows feedback-based fuzz testing to execute 1000x faster compared to external approaches over the network faster. And it allows tests to run highly efficiently as it tests what is relevant for the code. With the additional benefit of generating code coverage. Teams know exactly what code has been tested and where there are still gaps.

The result: feedback-based fuzzing finds all the code issues that later stages might have found with much higher effort or customers may have found and even worse: hackers might have exploited. Developers can take advantage of fuzzing during development of an API to find all types of defects even before deploying a service to an internal test environment. 


Show Me Some Code

In the video, CI Fuzz is used to test the API endpoints of a typical Spring Boot Microservice. The single test creates thousands of inputs, each input is tested as fast as any comparable Unit test. The test cases are generated based on code feedback and not just random or heuristical, which makes them highly efficient and helps even to avoid writing a test manually.

The test also summarizes the return codes to instantly assess its effectiveness and the impact of any issue on the API users. An issue will be created automatically for every return code in the 5xx family. 

What Kind of Issues Can You Find with Fuzzing

CI Fuzz allows you to find all types of issues related to missing, wrong, and even additional parameters. Any input that might lead to an exception in your API or cause long response times. You can even test business logic by doing property-based testing.

And even your colleagues from the security team value CI Fuzz as it finds all typical issues hackers would use to attack the API successfully. Reports are available to cover the needs of any compliance requirements you may have. Click here to see the full list.

 

Category

Reference

Severity

 

Broken Access

OWASP A01:2021

critical

 

Cryptographic Failures

OWASP A02:2021

critical

 

Injections (XSS, SQL, …)

OWASP A03:2021

critical

 

Insecure Design

OWASP A04:2021

critical

 

Security Misconfiguration

OWASP A05:2021

critical

 

Vulnerable and Outdated Components

OWASP A06:2021

critical

 

Identification and Authentication Failures

OWASP A07:2021

critical

 

Software and Data Integrity Failures

OWASP A08:2021

critical

 

Security Logging and Monitoring Failures

OWASP A09:2021

critical

 

Server-Side Request Forgery

OWASP A10:2021

critical

 

Improper Neutralization of Input During Web Page Generation

CWE-79

high

 

Sensitive Cookie with Improper SameSite Attribute

CWE-1275

medium

 

Sensitive Cookie Without 'HttpOnly' Flag

CWE-1004

medium

 

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute

CWE-614

medium

 

Insufficient Logging

CWE-778

medium

 

Logging of Excessive Data

CWE-779

medium

 

Exposure of Sensitive Information to an Unauthorized Actor

CWE-200

high

 

Generation of Error Message Containing Sensitive Information

CWE-209

high

 

Failed Assertion

CWE-617

low

 

Uncaught Exception

CWE-248, CWE216

low

 

Logic Issues

CWE-840

low

 

Infinite Loops

CWE-835

low

 

Denial of Service (DoS) 

CWE-400

low

How to Get Started with REST API Testing

I hope you now have a broad overview of REST API testing and the different approaches to it. If you are curious about how fuzz testing can help you build your business on highly reliable web apps, check out CI Fuzz. This tool provides support for common languages in web development such as Java and Kotlin and can effectively be used to fuzz server-side code during development. All you need to run it is a working unit test. After installing you can call CI Fuzz straight from the command line or directly in your IDE. For Java is deeply integrated into JUnit, so you can use the annotations you are used to, like @FuzzTest instead of @Test. If you ever ran a unit test, you can use it. If you use Spring Boot, there is even more. CI Fuzz will automatically generate basic tests for all your endpoints you can view in your IDE and modify as needed.

FAQs

What Is a REST API?

REST (Representational State Transfer) is a highly popular web API type because it offers flexible, fast, and simple communication between RESTful web applications. Compared to other API formats, REST is by far the most used, as over 80% of public web APIs are RESTful. Although stateful REST APIs are theoretically compatible with any protocol or data format, they mostly communicate through HTTP, using JSON, XLT, HTML, XML, or simple text. Out of these data formats, JSON is the most common as it is compatible with most languages.

Their adaptability makes REST APIs especially useful for services that are growing in complexity. Thanks to their ability to process commands from multiple users and different data formats, REST APIs are highly popular in various industries, such as e-commerce or IoT. 

REST APIs use five main HTTP methods to request a command:

GET: Retrieve a resource
POST: Create a new resource
PUT: Update an existing resource
PATCH: Modify an existing resource
DELETE: Delete an existing resource

Below, you can see an example of a POST request:REST-API-example

 

What's the difference between REST and SOAP APIs?

The main difference between REST and SOAP (Simple Object Access Protocol) is that to be RESTful, an API has to simply meet a specific set of characteristics. Meanwhile, SOAP is an actual protocol, built to enable applications to communicate across languages and platforms. REST APIs are generally seen as more flexible and faster than SOAP protocols. Although SOAP protocols slightly decrease the speed of web services, they provide several features such as improved security, atomicity, consistency isolation, and durability (ACID). SOAP interfaces can process multiple protocol types (HTTP, SMTP TCP, etc.). However, SOAP return messages are always sent in XML. Thus, while REST APIs enable flexible high-speed communication, SOAP web services are slightly slower but offer more built-in functionality.

What's the difference between REST and gRPC APIs?

gRPC (Remote Procedure Call) is a Google-developed open-source data interchange mechanism that uses the HTTP/2 protocol. gRPC APIs exchange data using the Protocol Buffers binary format (Protobuf), which imposes standards that developers must follow when creating or using gRPC web APIs. While REST APIs are mainly useful for microservice architectures and third-party apps, gRPC is often applied in IoT systems, browserless mobile apps and applications with multiplexed streams.

What are the different types of API tests?

API tests are not only done for security but also for other reasons, such as performance, functionality, and stability. Which testing approach is the right one for your REST APIs strongly depends on what you are trying to achieve. However, most modern API testing tools can be used for more than one form of testing. Generally, REST API testing approaches include:

Unit Testing: Testing the functionality of individual operations

Integration Testing: Testing the interaction between multiple software modules 

Functional Testing: Ensuring that REST APIs behave exactly as it should

Load Testing: Measuring how many calls REST APIs can handle

Reliability Testing: Ensuring that REST APIs produce consistent results and connections

Security Testing: Validating REST API encryption methods and access control