1 min read

API Excessive Data Exposure: Why Devs? Why?

API Excessive Data Exposure: Why Devs? Why?

API Excessive Data Exposure

When the API sends extra response to the client than required, it is called as API Excessive Data Exposure. In layman's terms, client wants x but API sends x+y.

Is x+y a bug?

I am not saying x+y is a bug, but it can be.

For example, A client requires firstname and country to be visible on a public profile. API response contains username, firstname, country, countryCode, phonecode, avatarUrl, and isAdmin parameters.

This is not a bug. You can argue that this parameter isAdmin is extra here. Well, it's just a true/false value. You can use this to chain it with your further IDOR or BAC bug to get admin's data, but it's not worth reporting.

When is x+y a bug?

If excessive user personally identifiable information (PII) data, system data, internal data, infrastructure data, etc. is leaked in the API response. And, only when it's excessive or unauthorized.

For example, A client requires firstname and country to be visible on a public profile. API response contains email, auth_token. It's worth reporting.

One more, An error message is thrown, but within the API response contains errorCode, description, and whole stackTrace with internal paths, system usernames, etc. This is worth reporting.

Why does this happen?

Devs sometimes let the frontend server or client-side JS do the filtering for API responses. This creates a security hole because by hitting the API call, attacker can get more data then required if excessive data is present.

Conclusion

Today we have SOAP APIs, GraphQL, RestAPI, gRPC, WebSocket API, etc. Every API have different way of dealing with the HTTP request. Play with the requests and always watch carefully what is present in the response. If x is required, and x+y is visible, where y looks impactful, you just got a bug!

Author: Inderjeet Singh
Twitter: https://twitter.com/3nc0d3dGuY
Happy Hacking!!