API10:2023 Unsafe Consumption of APIs - validate may be problematic

[gavjl]

"Does not properly validate and sanitize data gathered from other APIs prior to processing it or passing it to downstream components;"

Performing validation on input from a third party may cause an error which a user of the service cannot fix e.g.

1) user sends a request to the API to do something 2) API takes user data and makes request to third party API 3) response contains invalid data and results in error 4) user can't do anything to fix it

While input validation is important, the only truly valid schema is that applied by the third party, as it's their data.

Performing your own input validation might be useful to log issues, but blocking invalid data would be very complex.

The focus should be on sanitization at the point of use - parameterized SQL calls, output encoding for HTML etc

[LaurentCB]

Maybe you could delegate user input validation to the third party API. It depends if your API has to use it or not. But it is likely that your API will use a client to connect third party API and it would be a pity to let users making advantage of your API to trick or attack a third party...

I think the essential part of this chapter is "Always validate and properly sanitize data received from integrated APIs before using it"

it means third party API response data can not be trusted ! The same way as user inputs that cannot be trusted either.

Even if the third party is gogol, instrgrim or fatebook

[ErezYalon]

@gavjl, don't you feel that your suggestion:

The focus should be on sanitization at the point of use - parameterized SQL calls, output encoding for HTML etc

is exactly "properly validate and sanitize data gathered from other APIs prior to processing it"

[gavjl]

@ErezYalon - validate is a problem if it actively blocks responses from the third party API, which is typically the intent of validation.

I'd suggest either:

• Does not properly sanitize data gathered from other APIs prior to processing it or passing it to downstream components (i.e. removing the validate)

or

• Data gathered from other APIs isn't sanitized when used with potential injection targets such as SQL queries and HTML (i.e. still without validate, but a little more focused on the reason for vulnerability)

Being extra picky: "The API might be vulnerable if:" should be: "The API might be vulnerable if it:"