search

OWASP / API-Security

OWASP API Security Project
https://owasp.org/www-project-api-security/
Other
2.07k stars 377 forks source link

API10:2023 Unsafe Consumption of APIs - Conflicting vulnerability indicators #80

Closed ynvb closed 1 year ago

ynvb commented 1 year ago

Under the "Is the API Vulnerable?" section, two examples appear that IMO is out-of-scope for this category:

  1. Interacts with other APIs over an unencrypted channel This conflicts with API7:2023 Security Misconfiguration - as this category clearly states (and rightfully so) that usage of HTTP instead of HTTPS is a configuration issue.
  2. Does not limit the number of resources available to process third-party services responses This conflicts with API4:2023 Unrestricted Resource Consumption - as this category clearly states (and rightfully so :) that resource consumption can lead to a security issue.

I would, therefor, humbly recommend removing these indicators from the API10 category and integrating them where applicable in the other, more relevant categories.

LaurentCB commented 1 year ago

Yes there are API Security Misconfiguration, but on a third party API and I think this the important point.

You have to be cautious when configuring an owned API or server but also when consuming others on which you have no (or limited) power.

Beside, isn't repeating thing a good way to teach newcomers in the field ? 😅

ynvb commented 1 year ago

Well, OWASP TOP-10 always stood out as an excellent way to categorize attacks. The most crucial thing about good categorization is trying to prevent overlaps as much as possible so that each attack will be as unique as possible to its category. I think the categories are OK, but the choice of examples could be better. Another type of use case can be found that will not overlap with other categories.

And while I agree with your point about the need to better teach the field - I just don't feel this is the way to do it. My 2 cents...

ErezYalon commented 1 year ago

I agree with both of you. It is natural to encounter overlaps between categories that are sometimes very general. While the issues you raised, @ynvb, are correct for API4 and API7, they are mentioned there for exposed endpoints - the APIs you, as a developer, serve. API10 is focused, as @LaurentCB wrote, on consuming third (and second) party APIs.

We are collecting and rewriting the API10 category according to all the feedback received. We will make sure to make it clearer. Thank you both!