How to fix: Excessive Data Exposure

Context

Developing an API is already a complicated task. Therefore, it is normal for most teams to focus on working efficiently and forget about the security of what they develop.

In the early stages of a project, working this way makes sense because the focus is on speed, whether it's getting an MVP ready or hitting a big launch date on time. However, as companies get bigger, they become targets for cybercriminals. Therefore, as a company grows, it must increasingly focus on secure development, thus replacing efficient development.

A single cyber attack can cost a large company hundreds of thousands of dollars in loss. Furthermore, after an event like this, reputation is the most difficult thing to recover.

For this reason, it is best that teams learn to develop safely at the earliest possible stages. In Strike, we have developed a series of articles with which you can learn that skill. Not only that, but we have also created an ebook that you can use as a checklist every time you want to develop an API. You can find it at this link: https://discover.strike.sh/api-guide

In this article, we will specifically deal with one of the TOP 10 problems that can arise when developing an API. Discover how to deal with: Excessive Data Exposure

Excessive Data Exposure

Description

A request response returns more data than truly required to perform the desired function.

Is my API vulnerable

Checklist to know if your API is vulnerable:

• The API returns full data objects from database, with sensitive data to the client by design.
• Data is filtered on the client-side instead of the backend.
• An attacker can easily sni! the tra"c and see sensitive data.

Example Attack Scenario

The mobile team uses the /api/service/{serviceID}/reviews/{reviewID} endpoint in the reviews to render comments metadata. Sni!ng the mobile application tra!c, an attacker finds out that other sensitive data related to the comment’s author is also returned. The endpoint implementation uses a generic toJSON() method on the User model, which contains PII, to serialize the object which returns the entire DTO.

{"user_name":"santi","age":25, phone_number":"+59898000111","comment":"Good Service”}

Checklist to prevent

• Never perform data filtering on the client side.
• Review the responses from the API to make sure they contain only legitimate data.
• Make sure errors only return the necessary information.
• Define all sensitive and personally identifiable information (PII) that your application stores and work with and review all API calls returning such information to see if these responses can be a security issue.

Conclusion

We hope you found this information useful! This is just one of many articles that we are writing to spread as much information as we can to improve the skill of developing securely of developers all around the globe. If you found this article useful, feel free to discover more on our blog.

Also, our CEO created an impressive guide on how to develop APIs securely for internal use. However, we are committed to making cybersecurity accessible, so we are releasing it for free. Discover the full-length, 77-page guide, just a click away: https://discover.strike.sh/api-guide