Slide 14 of 28
Part 3 · Attack ScenariosSlide 14
PART 3
Attack Scenarios
Slides 14–17 · Three scenarios from the OWASP spec
Slide 14 · Scenario 1
SQL injection delivered through a third-party address validation API.
The consuming API validates user-submitted addresses. It doesn’t validate what the address validation API sends back.
📄 OWASP API Security Top 10 2023 · API10:2023 Example Attack Scenarios
SCENARIO 1
Injection via third-party address enrichment response

An e-commerce API accepts user shipping addresses and validates them against a third-party address standardization service. The service returns the canonical form of the address: corrected spelling, full postal code, and standardized format. The API stores the validated address returned by the third-party — not the user’s original input — in the database.

The database insertion uses string concatenation rather than parameterized queries, because the developer reasoned that the address came from a trusted validation service: query = "INSERT INTO orders (address) VALUES ('" + validated_address + "')"

An attacker compromises the address validation API. For addresses submitted by the attacker, the API returns a crafted string: ', (SELECT password FROM users WHERE username='admin')); --. The consuming API inserts this directly into the SQL query without parameterization. The SQL executes as: extract the admin password and insert it into the orders table. The attacker queries their own order to retrieve the extracted credential.

The API10 failure: The consuming API applied input validation to user-submitted addresses before sending them to the third-party. It applied no validation to what the third-party sent back. Third-party responses bypassed the parameterized query requirement because they were considered trusted.
← Back Scenario 2 →