A transit API gateway assessment must classify injection findings correctly. Which distinction best separates SQL injection from command injection?
Select an answer to reveal the explanation.
Short Explanation
Different pipes, different problems: SQLi messes with the database question, command injection messes with the shell. Mixing the labels turns a transit API report into alphabet soup.
Full Explanation
Correct classification separates SQL injection from command injection by sink and effect. SQL injection targets database queries—manipulating SQL syntax through application inputs to read, alter, or infer data. Command injection targets operating-system or shell command execution paths—smuggling OS metacharacters or arguments into APIs or helpers that spawn processes. On a transit API gateway assessment, that distinction drives accurate findings, remediations (parameterized queries vs safe process APIs/allowlists), and prioritization.
Treating the terms as interchangeable labels for any malformed JSON collapses two different vulnerability classes and confuses developers. Claiming command injection only occurs in mobile apps and SQL injection only in email is geographically and technologically false; both appear widely in web and API layers. Asserting both always require physical USB implants denies remote web/API injection paths that municipal gateways actually face.
Exam caveat: taxonomy questions reward DB-query vs OS/shell-command distinctions and reject interchangeable-label myths. Operational check: for each injection finding, name the sink (SQL engine vs OS command), evidence the channel, and recommend the matching control family.