Authorization issues should be under the same umbrella

[PauloASilva]

Authorization: Why are there 6 of 10 issues related to authorization. 1, 3, 4, 5, 8, and 10 are all problems with authorization. Can we combine these? It doesn't make sense to break these out and bump critical problems like Injection, crypto failures, and insecure libraries. All of which are rampant and highly dangerous in APIs.

(Source: issue #77 by @planetlevel)

[inonshk]

We do not consider API#4 (Unrestricted Resource Consumption), API#8 (Lack of Protection From Automated Threats) and API#10 (Unsafe Consumption of APIs) authorization issues. Authorization issues are defined as problems in the authorization mechanism (weakness or lack of). Also, like many aspects of security, the borders are sometimes not 100% clear. We decided to adhere to the main mechanism and reasons that cause the issues.

We agree that combination of similar categories makes a lot of sense sometimes, like we did with API#3 (Excessive Data Exposure) and API#6 (Mass Assignment) moving from the 2019 version to the suggested 2023RC version. But we need to remember that the fact that different categories could be combined under the same umbrella, from a theoretical perspective - does not mean they should be combined. The more issues you combine under the umbrella, the less focus you give to each sub-issue.

Different categories should be merged/split based on three factors:

1. How similar is the process of exploiting these issues
2. How similar is the process of remediating or protecting against these issues
3. How severe/prevalent they are

We strongly believe that this methodology of categorization is the correct way when building an awareness document. It seems like the community agrees, as can be seen in the categorization methodology examples from the general OWASP Top 10:

• In some cases, like “Security Misconfiguration” - where you can find many different issues falling under the same umbrella, it makes sense to merge them. For example: even though protection/exploitation of “insecure headers” is very different from protection/exploitation of “default credentials", they are still under the same category - because they don’t justify their own categories.

• In other cases, like “Cross Site Scripting” and “Injections” - it does not always make sense to combine them. There many common points between the exploitation/protection process of XSS and Injection, such as: -- Exploitation requires you to inject code/script -- Protection requires you to sanitize the input from the client before concatenating it the the command/script -- Cross Site Scripting can be easily thought of as “Script Injection” Even when considering those common points, while XSS deserved special attention, due to prevalence/risk, it wasn't merged into Injection for many years.

We deeply believe that Broken Object Level Authorization (BOLA/IDOR), Broken Function Level Authorization (BFLA), and Broken Object Level Property Authorization (BOPLA or Mass Assignment/Excessive Data Exposure) deserve their own places in the list, because how prevalent they are and how different is the approach to protect against each one of them.

[planetlevel]

I understand how hard it is to create groupings. But one key requirement that you left off the list is that you have to cover all the top risks to APIs. And by breaking out authorization into so many subcategories, you not only lower the risk of each one, but you also bump out all the more serious issues that I detailed in the rest of this post.

Can you seriously argue that mass assignment (infrequent, often harmless) is more serious than the use of insecure libraries in APIs (incredibly prevalent, often highly dangerous)? You're going to have to show me some data.

Can you produce a big table that shows all of the items you chose as well as the ones I suggested? For each one, put some numbers for how prevalent they are, and their security impact? At least that way we could argue about whether the numbers are right or wrong, and not what you "deeply believe."

[jmanico]

Can you seriously argue that mass assignment (infrequent, often harmless) is more serious than the use of insecure libraries in APIs (incredibly prevalent, often highly dangerous)? You're going to have to show me some data.

This is a very solid argument that I agree with. Mass assignment is infrequent and harmless and does not really have a place in any security top ten list. Third party libraries is one of the absolutely top risks in tbe world of API’s. And there is solid data to back this conjecture.

I much rather see this project be complete and not require me to read other standards and other top ten lists first.

[inonshk]

Before replying to the rest of the comments, I just want to mention that on the new list, "Mass Assignment" is combined with "Excessive Data Exposure". It is not an issue that stands by itself. You can find more information here: https://github.com/OWASP/API-Security/blob/master/2023/en/src/0xa3-broken-object-property-level-authorization.md

[planetlevel]

Fair enough. This was just one example of the problem. And in any case, I don't think this changes the calculus in a significant way. FTR I'm not convinced that these two areas share the three factors you noted for why categories should be merged.

[securitylevelup]

Seconded on the many Broken X Level Authorization categories in place in the new draft. Mostly BOLA, BOPLA and BFLA. While it makes sense to combine Excessive Data Exposure and Mass Assignment into BOPLA, the order of the list is also throwing me off.

Is it possible to group BOLA, BOPLA and BFLA in order and not have Broken Authentication and Unrestricted Resource Consumption break this up? Is this order chosen based purely on the severity?

From a learning / education perspective, I think it makes more sense to group these things in order. I would even argue to combine BOLA and BOPLA into one category but that might be too much of a shift.