11 DevOps Maturity Assessment Questions to Ask During the Audit
- April 02
- 6 min
API testing is an indispensable part of the development process for modern applications. Although it is often associated mainly with the verification of HTTP response codes (e.g. 200 OK, 404 Not Found or 500 Internal Server Error), in reality effective API testing goes much deeper. To ensure the quality, security and stability of the system, it is worth paying attention to less obvious but crucial aspects as well.
Obviously, proper selection and testing of HTTP status codes is a must. However, response codes are just the tip of the iceberg. Logical errors or incorrect statuses can confuse API clients. But just checking that 200 was returned doesn’t mean everything is working as expected. What if the response contains too much data? Or if vital information is missing?
One of the most common problems in API design is sending excess data that should not be available to the client. This is especially true for information that is confidential or irrelevant to the functionality of the system but nevertheless ends up in the API response. Examples of such data include passwords, ID numbers, payment card data or other fields that should remain exclusively on the server side.
{
"id": 123,
"name": "Jan Kowalski",
"email": "jan@kowalski.pl",
"pesel”: “11111111111",
"isActive": true,
"createdAt": "2021-06-01T12:00:00Z",
"internalNote": "User migrated from legacy system"
}
Threats:
PESEL (ID number) is a special category of personal data under the GDPR. It should not be transferred anywhere where it is not absolutely necessary.
Why it is not good:
The internalNote field contains administrative information that does not have any impact on the operation of the application on the client side. This type of data is unnecessary in the context of making the application available to the user.
Why it is not good:
Excess data can also refer to information that does not make sense from the point of view of the business itself or the very process for which the API is used. Sending unnecessary data not only increases the volume of responses but can also lead to confusion on the part of users and increase query load.
{
"appointmentId": "A-100",
"date": "2024-04-15",
"doctor": {
"name": "dr Kowalski",
"startWork": "21.01.2004",
„contractType: "UoP",
}
}
Why it is not good:
Including information such as the doctor’s start date or contract type in the API response is an example of excess disclosure of data that is irrelevant to the user booking the appointment.
API testing should include a careful analysis of excess data that may appear in server responses. This is because it is often the case that APIs return more information than is necessary for the operation of the application. Such a situation can lead not only to inefficiency but also pose real threats to data security.
First and foremost, API responses should contain only the data that is actually needed for the proper functioning of the application. Excess information can create unnecessary confusion, increase the size of the transmitted data, and make analysis and debugging difficult.
In addition, special care should be taken to avoid accidental disclosure of sensitive data, such as user IDs, system internals or configuration details. Any such information, however seemingly insignificant, can be used in a potential attack.
It’s also a good idea to avoid overly detailed answers that may reveal system logic, data structure or other technical information. This not only increases processing and data transmission time but also increases the surface of potential attacks.
Therefore, one of the key aspects of API testing should be checking that the returned responses are optimized in terms of content – precise, secure and relevant to the needs of the application and its users.
TIP: You can create and use a standardized checklist, which might look like this, for example:
Interested? Check out the next parts in this series:
Improve Your API: A Comprehensive Approach To Input Validation
API Testing Security Aspects – More Than Just Login Protection