Differentiation Between OWASP Top 10 and API Top 10? about api-security HOT 8 CLOSED

+1 on planetlevel's comments here. The way I have always interpreted OWASP's top 10 is that they are the most important security threats for a given category at the time of the lists release.

If the point of the 2023 list is to be an addendum, I would recommend turning it into the OWASP API top 15 or 20 to encompass everything.

Creating two essential lists for API developers to have to go through will cause unnecessary confusion which list to use, which is more relevant etc.

from api-security.

I expected the OWASP API T10 to be more like an interpretation of the risks in the Main T10 for APIs. This can add a tremendous amount of value. It could also definitely include API-specific risks -- or risks that didn't make the cut for the Main T10 but the data shows that they are more risky for APIs than for other types of apps.

from api-security.

Thank you all for the comments.
It is now evident that we should have published a clear intro together with the Top 10 list.
We didn't, but we are working on it now. I am sure it will answer all or most of the above questions.

from api-security.

If the intent to be take the OWASP Top 10 and describe how the vulnerability classes map to API concerns, I would definitely agree with you that there is value in that. However, that is not how this named, described., or implemented. It comes off as another Top 10 that should be monitored for and I don't see how that benefit outweighs the risk of miscommunication to the non-security world.

If there are different findings in API-Specific worlds that are more frequent than have shown up in the Main T10, I'd love to see the data analysis between the two to better understand it.

Each of the ones in this list, I see as direct duplications or extremely similar to problems I have seen in older Web Apps as well. And the one that I love (resource management), I'm surprised hasn't made the Main T10 explicitly (I know logging and monitoring can cover it).

from api-security.

I agree that it is becoming harder to see the distinct differences between the Web App Top 10, API Top 10 and now also the CI/CD Top 10. All are relevant for any API microservice out there, duplicating categories without making them specific enough to their respective bucket (Web App architecture, API architecture, CI/CD tooling) will make this a challenge to follow / maintain.

I would expect to see in the API Top 10, 10 unique risk that are catered specifically to APIs with examples on API architecture with a 'more resources' at the end.

As an API developer, can I exclusively focus on the API Top 10 and know that I will cover the majority of my threats out there? If the answer is yes, that is the right approach to take.

from api-security.

An introduction doesn't come close to answering these comments. The API Top Ten should be the top ten risks to APIs. Not an addendum to the main T10. I don't believe people will read or understand an introduction explaining this approach - because it doesn't make sense. This approach, whether there's an introduction or not, will cause a lot of confusion and harm a lot of organizations, including OWASP.

from api-security.

The traditional top 10 list is not a most important list, it is a most prevalent list - Jim Manico has been pointing this out for years. In particular, then the other top 10 lists should be of the same character ; or (less than ideally) have a different origin and hence slightly different use case. In particular I got here by looking at what Microsoft says about Defender for APIs, and I am unsure now whether they have it right or not (if they were using the traditional Top 10 they would have made the mistake I just alluded to).

from api-security.

Hi @keithdouglas,
I don't know whether Microsoft did it write or wrong regarding what they say about Defender for APIs, nevertheless if you would give me one hour of your attention to talk about API security the ten items we've put together for 2023 would be our agenda. In such a case I am sure you would bring other security topics to the table (otherwise I would do it myself) and we would discuss how they apply to APIs.

Security won't fit a list of 10 items and our attention is limited.

Cheers,
Paulo A. Silva

from api-security.