Lack of injection in 2023 API10

[cyn8]

Hi team,

I have noticed whilst going through the new API10 guidelines that there is no dedicated page for injection-based attacks. I realise going into 2023, pure injection-based are becoming less common, but I believe it should still be prevalent enough to test for these issues?

Is it intended for the 2023RC that the injection category is removed?

[planetlevel]

Take a look at the issues starting with #77. The team excluded injection because they think it's not specific to APIs. It doesn't matter that recent reports have shown it to be the largest attack vector on APIs. The philosophy is that this T10 should only include things that are uniquely risks to APIs. I think this is wrong and will mislead teams to ignore critical problems like injection on APIs.

[ynvb]

@planetlevel - to further strengthen your point:
If this list is supposed to include only attacks unique to APIs, why is there a new "SSRF" category in this list? This is clearly not an exclusive attack on APIs - but it is very relevant (which is why I believe it found its way into the list).

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

[cyn8]

@ynvb

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

Could you link me where injections are included in the 2023 API10? I can't seem to find them.

[securitylevelup]

After a GitHub search in the repo, I see two mentions of 'Injection' now in API10 with two additional links. This is definitely not enough focus on API Injection attacks, especially with the threat of GraphQL Injection attacks looming ahead.

https://github.com/OWASP/API-Security/blob/c56e753eb08e28c6c6d4d756bb3038bcc0ca804a/2023/en/src/0xaa-unsafe-consumption-of-apis.md

[llegaz]

I think Remote Execution is not mentioned either.
IMO, that points well the lack on the injection topic and the threats that are overlooked here.

[tebbers]

@planetlevel - to further strengthen your point: If this list is supposed to include only attacks unique to APIs, why is there a new "SSRF" category in this list? This is clearly not an exclusive attack on APIs - but it is very relevant (which is why I believe it found its way into the list).

Also, Injections were not excluded - they are part of API-10 - however, I agree it is not very clear to understand that reading trough the categories description.

And isn't an SSRF just one TYPE of Injection? Why leave the others out and just name that one...Seems odd to not have all of the injection types in one place.

[planetlevel]

SSRF is a top-level item in main OWASP T10 (as opposed to being included in the Injection category). I expect that someday it will be subsumed into the injection category. But this decision was made based on an absolutely massive data collection effort and months of data science by a highly qualified team. Personally, I support having SSRF as a top-level category for APIs... but that's because I have a ton of data about how prevalent this vulnerability is for APIs and how often it is attacked in production.

[tebbers]

SSRF is a top-level item in main OWASP T10 (as opposed to being included in the Injection category). I expect that someday it will be subsumed into the injection category. But this decision was made based on an absolutely massive data collection effort and months of data science by a highly qualified team. Personally, I support having SSRF as a top-level category for APIs... but that's because I have a ton of data about how prevalent this vulnerability is for APIs and how often it is attacked in production.

Is that data public that we can all look at? @planetlevel

[planetlevel]

I offered to share data with the project leads, but never heard anything back.

[d0znpp]

I shared this, but no feedback. According to what we see in CVE and bug bounties, Injections are API1:

Hi guys!

I finally did that! The classification and data source is available here:
https://drive.google.com/drive/folders/1IyygtOohhCWlA-mbHUw9w-xgv0dXn7v3?usp=share_link

That's all the CVEs, HackerOne, and more than ten other sources.
Mapped to CWEs.

[ErezYalon]

Hi team,

I have noticed whilst going through the new API10 guidelines that there is no dedicated page for injection-based attacks. I realise going into 2023, pure injection-based are becoming less common, but I believe it should still be prevalent enough to test for these issues?

Is it intended for the 2023RC that the injection category is removed?

Hi @cyn8,
Yes, the general Injection category was removed.
The OWASP API Security Top 10 is an awareness document that expands the general OWASP Security Top 10. Being an expansion, we tried to cover categories unique to APIs, categories that have different consequences/mitigations/mechanisms in APIs, or categories that have a particular interest in an API-centric application.
Injections are indeed prevalent. But they exist in every application regardless of whether it uses APIs.

[ErezYalon]

I shared this, but no feedback. According to what we see in CVE and bug bounties, Injections are API1:

Hi guys!

I finally did that! The classification and data source is available here: https://drive.google.com/drive/folders/1IyygtOohhCWlA-mbHUw9w-xgv0dXn7v3?usp=share_link

That's all the CVEs, HackerOne, and more than ten other sources. Mapped to CWEs.

Thanks, @d0znpp, for the effort, but you sent the data after the call-for-data was closed and not in the requested format.

[LaurentCB]

The OWASP API Security Top 10 is an awareness document that expands the general OWASP Security Top 10. Being an expansion, we tried to cover categories unique to APIs, categories that have different consequences/mitigations/mechanisms in APIs, or categories that have a particular interest in an API-centric application.

A first page disclaimer (with this explanation written bold and an url link to the main OWASP Security top 10) as it has already be mentioned would be really nice for newcomers in order to understand the purpose of the project.

Because this project (as pointed out several times now) is REALLY perturbing especially for those accustomed to the main Top 10 for years.

Regards,
L.

[planetlevel]

I disagree with the "expands main T10" philosophy. But if that is the plan, then I suggest you delete these categories which are duplicated from main OWASP T10:

• 0xa2-broken-authentication
• 0xa6-server-side-request-forgery
• 0xa7-security-misconfiguration

If you're planning to stick with some that duplicate the OWASP T10, then I suggest the first one you ought to duplicate is Injection.