Recommendation to combine API4:2023 & API8:2023

[securitylevelup]

Thanks for the great work so far on the new OWASP API Top 10 list for 2023! I have gone through the proposed 2023RC and agree for the most part on the changes to the 2019 list.

I struggle the most with the newly created API8:2023 Lack of Protection from Automated Threats. While it is very important to highlight the threats of automation through bots etc. I don't believe this should be a category on it's own. I see a major overlap with API4:2023 Unrestricted Resource Consumption which handles the same threat.

The way I read both is that API4 is the what element of API architecture is being threatened and API8 is the how element of how attackers are targeting the elements mentioned. Why was this chosen to be split across two distinct categories?

My recommendation would be to combine both into one, highlighting the importance of monitoring resource consumption (including third-party costs such as cloud providers / API gateway tooling etc.) while also applying the limits / validation to prevent resources from any type of malicious consumption whether that be human / targeted attempts OR automation / massive attempts.

Coincidentally, this would also free up another slot to retain the Injection category which I second the feedback already submitted that this should not be removed. If needed, I could help supply data to back up the amount of Injection attacks seen on API level.

[securitylevelup]

Also, the name / wording of API8 does not fit very well / adhere to the others in the list: Lack of Protection from Automated Threats.

[planetlevel]

My take on this issue is that missing attack detection and prevention is a key risk. Without some mechanism to detect attacks, API owners are blind to what's happening in production. This shouldn't be limited to automated attacks.

I see resource consumption as an access control issue... but there are different types of resource consumption. Attack could consume all memory, CPU, bandwidth, file space, or any other limited resource.

[ErezYalon]

Thanks for the great work so far on the new OWASP API Top 10 list for 2023! I have gone through the proposed 2023RC and agree for the most part on the changes to the 2019 list.

Thanks @securitylevelup, good words are always fun to receive.

My recommendation would be to combine both into one...

Let's hear more from @inonshk and the rest of the community about that.

Also, the name / wording of API8 does not fit very well / adhere to the others in the list: Lack of Protection from Automated Threats.

Can you recommend a more suitable name for the category?

[securitylevelup]

Of course, this has been a very helpful resource for API Security for the community out there.

As mentioned, it has my preference to combine API4 and API8 together so the naming of API8 disappears if that were to happen. But if it stays in, my recommendation would be: "insufficient automated threat prevention" which fits better in the flow of the other categories while continuing to focus primarily on automated threats.

Another recommendation would be the older term "Insufficient anti-automation" which has been floating around before in the web application security space and has been mentioned before by the likes of CWE. Not sure if there would be an objection on reusing that term.