Parameterized queries (prepared statements) separate SQL code from data, making injection impossible regardless of data content. This must apply to values from third-party API responses inserted into SQL, not just user-submitted values. There is no safe shortcut: “this came from a trusted API” does not make string concatenation safe.

HTML escaping (converting < to <, > to >, etc.) must be applied whenever any dynamic value — including values from third-party APIs — is rendered in HTML. Use a templating engine with auto-escaping enabled (Jinja2, Handlebars, React JSX) and never bypass escaping for “trusted” sources.

Before passing any external value — including third-party API response fields — to a logging call, strip or encode JNDI lookup patterns (${, #{, %{). Update logging libraries to versions with lookup evaluation disabled (Log4j 2.17.1+ disables JNDI by default). Apply -Dlog4j2.formatMsgNoLookups=true or equivalent as an additional layer.

Define an expected schema for each third-party API response (field names, types, lengths, formats). Reject responses that don’t match. A compromised API that injects SQL in an address field will likely produce a value that doesn’t match the expected format for a street address. Schema validation is the first line of defense before field-level controls.