Why Effective Api Testing Goes Far Beyond 200 Ok

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? 

Excess Data – A Hidden Threat  

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. 

Example: User profile 

{ 

  "id": 123, 

  "name": "Jan Kowalski", 

  "email": "[email protected]", 

  "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 ID number enables a person to be uniquely identified 
• It can be used for identity theft (e.g., taking out a loan) 
• If leaked, it can carry serious legal consequences (e.g., GDPR penalties of up to €20 million or 4% of turnover) 

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: 

• Reveals implementation details and migration history – which can be used by attackers to find weaknesses in the system.  
• May contain administrative comments that should not reach the user (e.g., “customer difficult to work with,” “problematic billing”).  

• Creates risk of non-compliance with information protection policies. 

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. 

Example: Booking an appointment 

{ 

  "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. 

Summary: Why Analyzing Excess Data Is Key to API Success 

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:  

Checklist: Testing Excess Data in APIs  

Security and privacy  

• Does the response not contain sensitive data, e.g., password hash, ID number, tokens, session ID?   
• Are we not revealing technical data, e.g., user IP, login date, and administrative flags?  
• Are we not leaking business information, e.g., employee contract type, accounting data, and internal memos?  
• Doesn’t other users’ data accidentally end up in responses?  

Minimization and transparency  

• Doesn’t data from relationships that are irrelevant, e.g., full dependent objects instead of ID/name, get in?  
• Has the response model been deliberately “slimmed down” – containing only necessary fields?  
• Is the data not duplicated, e.g., the same information in several places?  
• Are the nestings in the JSON structure necessary and logical?  
• Is the size of the payload optimized?  
• Does the response not mix data for different contexts, e.g., user data and system data? 

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