Unsafe Consumption of APIs

[PauloASilva]

Why is this a separate item? Assuming an API consumes data from an untrusted API, isn't it only an issue if one of the other problems occurs? Put another way.... why isn't unsafe consumption of USER data a more important issue? Because it's already covered.

(Source: issue #77 by @planetlevel)

[ErezYalon]

As you wrote, @planetlevel, the consumption of USER data is covered in many places from #1 to #9.
We slightly touched on the topic of consuming data from APIs in the 2019 version, but we now believe it deserves its own category in order to create focused awareness.

Developers tend to understand they can not trust user input and development frameworks have played a significant role here. But these same developers will frequently accept data that comes from an API call without any worry. The main issue here is misplaced trust. We often see that developers tend to blindly trust data coming from third-party APIs, especially those offered/maintained by known companies. The goal of #10 (Unsafe Consumption of APIs) is to bring awareness to this topic, and make sure developers remember that anything that comes from an API call cannot be automatically trusted.

[planetlevel]

I think you missed the point of my comment. I'm saying that organizing by the source of potential attacks is orthogonal to the rest of your categories. Why not have unsafe consumption of queues? Or failure to protect from insiders? We could create a T10 organized around threat actor, attack vector, or even consequence. But it's confusing when you mix up the philosophy. Why not just make sure that each of the areas (including injection) details that APIs often call other APIs, and you have to consider that data untrusted?

FTR, this issue is at least as important to traditional web applications as it is to APIs, as they consume APIs very frequently. So this isn't exactly an issue that is specific to APIs.