Injection: Keeping Data Separate from Instructions

Injection is the next category in my OWASP Top 10:2025 study notes. After looking at access control, configuration, the software supply chain, and cryptography, this topic brings the focus to how an application uses the data it receives.

The question I am keeping with this category is: will this value stay data, or can it change the instructions a system follows?

That question applies to database queries, operating-system commands, browser content, and other places where software interprets structured input. OWASP's A05 overview groups several injection types around this common problem.

Following a value into a query

Imagine a customer search feature. A user enters a name, and the application asks the database for matching records.

If the application builds the query by joining the search text directly into the SQL, some input may be interpreted as part of the query itself. The search value can then change what the database is being asked to do.

A parameterized query separates the SQL structure from the values supplied to it. The database API binds the search value as data. A name containing an apostrophe should remain a name, rather than breaking out into SQL syntax.

There is an important limit here: parameter binding normally handles values, not arbitrary table names, column names, or query keywords. A feature that offers several sort orders can map the user's selection to a small set of application-defined choices. It should not treat the submitted text as unrestricted query structure. The SQL Injection Prevention Cheat Sheet explains these distinctions.

A framework still needs to be used safely

An object-relational mapper can provide useful ways to build queries. It can also expose interfaces for writing raw queries. Joining untrusted text into those queries can reintroduce the same problem.

Stored procedures need similar attention. A procedure that constructs dynamic SQL from untrusted input can still be vulnerable, even if the application calls the procedure through a parameterized interface.

This is a useful reminder for my notes: I need to follow how the value is used, rather than stop at the name of the framework.

The browser has its own context

Cross-site scripting is also part of this category. Here, the concern is untrusted content becoming active content in a browser.

Consider a hypothetical page that displays a customer's support message. If the feature only needs plain text, a text-rendering API avoids treating that message as HTML. If the application deliberately supports formatted HTML, it needs an appropriate, maintained HTML sanitizer and a clear policy for permitted content.

Output encoding also depends on where a value is placed. HTML text, attributes, JavaScript, and URLs have different rules. One generic escaping function cannot safely cover every destination. The Cross Site Scripting Prevention Cheat Sheet is a useful next step for that detail.

Validation is another layer

Server-side validation can check whether a value has the expected type, length, range, or permitted choices. Those checks help define what a feature accepts.

They still need to work alongside the right API for the destination. A valid business value may contain punctuation, and data received from another service or read back from storage can still be unsafe to insert into a query or page.

For operating-system tasks, avoiding a shell and using a suitable library can reduce exposure. Where external commands are necessary, the command, arguments, and allowed operations need deliberate handling.

Questions for my notes

Where does untrusted data enter this feature?
Does it later become part of a query, command, template, or page?
Does the chosen API keep values separate from instructions?
Are any framework protections being bypassed?
Are the output rules appropriate for the actual destination?

My takeaway

Injection makes more sense to me when I trace a value from its source to the place that interprets it. The useful question is what the receiving system will do with that value.

The next post moves further back in the development process, to Insecure Design.

Sources and further reading