API-Security
API-Security copied to clipboard
OWASP
Where is the data?
These categories are significantly different from the data from the hundreds of thousands of APIs that my company assesses and protects. This could give rise to suspicions that these categories aren't based on real world data. Could you provide a reference to the data set used and the data science performed?
At a minimum, I would love to know why the following categories from the main OWASP T10 don't apply to APIs:
- Injection
- Cryptographic Failures
- Insecure Design
- Vulnerable and Outdated Components
- Software and Data Integrity Failures
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.
SSRF: I'm glad to see SSRF show up here, mirroring the main OWASP T10.
Lack of Protection from Automated Threats: Interesting. And better than Insufficient Logging and Monitoring. But the big problem is that APIs don't detect or block any kind of attack. This category shouldn't be limited to automated threats. And how would you tell anyway?
Unsafe Consumption: 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.
Why point 8 should be authorization problem ? Couldn't automated threats be anonym ?
Furthermore, if all these point are merged won't this part be disbalanced in regard to the others ?
Don't get me wrong I'm not saying there are nothing to adjust here. I was also surprised injections or rate limiting weren't part of this top 10.
You are right user validation is only briefly mentioned at point 6, while rate limiting is only briefly mentioned at point 4.
I think (but it's my opinion), that this is a bit light, especially while insisting so much on AUTH, forgetting than some services could be totally anonymous without AUTH at all...
Of course authentication and authorization are vital, most of the time mandatory, but a lot of threats can be avoided with the two aforementioned techniques.
Not all authorization is based on identity. You can authorize based on time, tool vs human, location, volume of requests, etc... Any decision to allow or disallow something is authorization. By breaking out all these subcategories, the document encourages solving these problems separately, which ironically is a bad security design. Fortunately, "insecure design" wasn't included in this T10, so I guess it's not a problem for APIs.
Hi @planetlevel , Thanks for taking the time to review the release candidate.
Regarding the data set, the call for data (Cfd) was opened from September 1st to November, 30th 2022. We would have loved to have access to such data, but alas, no one contributed any data.
"... the data call goes out for anyone to contribute data. The project is open for anyone to participate in. Unfortunately, like most OWASP projects, it is a huge amount of work and very very few contribute.": you were right back in 2017 and it was no different on what to our Cfd concerns.
To come up with an updated API Security Top 10 list we followed the same approach we followed in 2019. We did an initial internal research based on publicly available data (e.g. bug bounty platforms, news): this is a preliminary work we do to get a sense of the most common reported issues which should also help us handle possible contributed data-bias. After the Cfd deadline, since there were no contributions, we moved forward based on our experience as practitioners to create a draft (something we also did back in 2019). The draft was then reviewed and discussed with more than a dozen API security practitioners (vendors and non-vendors) for a review before publishing the Release Candidate (RC). You can find their names here.
Hopefully this answers your "where’s the data?" question.
We would like to address your other questions in an organized and clear manner and make sure it opens the discussion to the community while keeping it in scope so we will open a separate GitHub issue per question/comment.
Lack of Protection from Automated Threats: Interesting. And better than Insufficient Logging and Monitoring. But the big problem is that APIs don't detect or block any kind of attack. This category shouldn't be limited to automated threats. And how would you tell anyway?
I would like to kindly ask you to open a new GitHub issue so that we can discuss your comment regarding "Lack of Protection from Automated Threats": we need more details from your side since your point was not that clear to us.
Cheers, Paulo A. Silva
I don't think your explanation tells the whole story. You've made clear that your philosophy for choosing categories is not based on figuring out what the biggest risks to APIs are. Instead, you've argued (in other issues) that the API T10 should focus exclusively on items that are:
- Unique to APIs
- Only apply to "modern" APIs (from the past few years)
I believe this will be extremely misleading to the population of users that just want to secure their APIs. They will probably (reasonably) think that if they address these issues they are secure. But that's not the case. They'll have to go through the regular T10, interpret them for APIs, and then go through this T10 as well.
I don't think that's good enough. If you go forward with this approach, I think you'll need some massive disclaimers about applicability and how you expect this document to be used.
I work a lot with clients exposing AI models through APIs and I've also seen a ton of SQL injection vulnerabilities, specially in "data-driven" applications with custom complex database queries written by hand. Often the team forgets to parametrize the values, and combined with lack of proper validation at the API layer, it allows to easily inject SQL attacks through the API.
