Encoding and Escaping Untrusted Data
Injection attacks are almost always the result of tampered data — unexpected input or formatting with the intent of discovering or exploiting vulnerabilities. The OWASP Top 10 Proactive Controls covers this under C4: Encode and Escape Data, which targets the core problem: distinguishing between data and the commands or markup that interpreters process. This is one part of a larger series on proactive security controls for OSS developers.
It wasn't until 2017 that OWASP stopped listing cross-site scripting (XSS) separately from "injection." Many security practitioners — including those at GitHub Security Lab — consider XSS a form of injection, making output encoding a valid defense against injection attacks generally.
Why Encoding Matters
The danger of injection is that it's inherently a what-you-see-is-NOT-what-you-get problem. Attackers exploit the fact that interpreters "helpfully" decode data at multiple layers, bypassing simple denylist approaches. Early attempts at defense often involved scanning for obvious markers like DROP, INSERT, or <script> in requests. This is fragile and maintainability-poor, and it fails completely when input arrives double-encoded — a malicious user can send %3Cscript%3E instead of <script> to slip past that filter.
Encoding works both ways: it's an attack technique, but output encoding (the defensive approach) is what renders untrusted data safe for a given interpreter. Most of the time that interpreter is your browser, which is why XSS is the most commonly discussed case. But the same logic applies to databases, command-line environments, or any other piece of software that processes input.
Output Encoding for XSS
XSS occurs when a malicious user's JavaScript gets injected into your browser and runs uninvited. The primary defense is output encoding: rendering a user-supplied < as <, so the page displays it as visible content rather than interpreting it as HTML source.
Context Determines the Encoding
Output encoding is not one-size-fits-all. The encoding must match the target context — where the content is being rendered in the browser. There are four primary contexts:
- HTML body — text between tags
- HTML attributes — text within the tags
- JavaScript — content between
<script>and</script> - CSS — content between
<style>and</style>
Each context requires a distinct encoding scheme. Encoding for the wrong context opens up a vulnerability. A real-world example: an application that had an XSS finding was encoding user data for JavaScript but emitting it into an HTML attribute instead. The code had simply been changed to a different output location without updating the encoding context — exactly the kind of subtle shift that makes manual encoding error-prone.
Given how easy it is to get this wrong, output encoding should be automatic, not something developers consciously manage. In fact, OWASP lists enabling automatic context-aware encoding as a "bonus" rule in its XSS Prevention Cheat Sheet.
Auto-Encoding Frameworks
OWASP's guidance is straightforward: output encoding should be applied just before content is passed to the target interpreter. This is where templating frameworks that default to safe encoding shine. They perform the encoding for you as part of rendering — you'd have to actively override or disable it to make them insecure.
Several popular frameworks and libraries have strong out-of-the-box output encoding:
- ReactJS
- AngularJS (and newer Angular, per their security documentation)
- Handlebars
- LiquidJS
- Rails
- OWASP's Java Encoder Project (a library, not a full framework, but purpose-built for this)
- .NET (which generally handles this well by default, per Microsoft's XSS documentation)
None of these are guaranteed to be XSS-proof forever, but they have solid defaults. If you choose a different framework or templating engine, research whether it auto-escapes content based on the right context before you rely on it.
Don't Undo the Escaping
Once you've chosen a framework that handles output encoding correctly, don't bypass it. Some frameworks make bypassing obvious — React's dangerouslySetInnerHTML is a clear warning sign. Others are subtler: Rails' html_safe can look innocuous in a template. When in doubt, read the documentation for the escape hatches your framework offers.
Encoding Beyond the Browser
The browser/XSS use case is the most visible, but encoding defends other contexts just as effectively.
SQL injection. Parameterized queries are the canonical defense here, and they're fundamentally a form of encoding. The insight: malicious input exploits the boundary between the control plane (the query structure) and the data plane (user-supplied values in a WHERE clause, for example). When those planes mix, users effectively gain control of the query itself — commonly via an unexpected ' that unbalances the syntax. Parameterized queries automatically encode the data so the input cannot alter the query structure. ORM libraries do this by default in most cases.
Command injection. Unexpected newline characters (\n) can bypass brittle validation that looks at only part of a string. Before validating, encode or normalize the input to ensure it's a single line. Make sure your regular expressions use the correct single-line anchors so you're actually validating the entire input, not just the first line.
Do the Encoding
When it comes to command injection, you'll often hit a wall where no amount of encoding or regex makes the input safe to execute. The more reliable approach is indirection: don't pass user input through to a system call at all. Accept predefined values — say 1, 2, 3, 4 — and map each one server-side to the actual file names and paths your code uses.
Encoding and validation will always add some friction to an application. That's not inherently bad — in a security context, it's the friction that lets you move quickly everywhere else. Like brakes on a car: they're what make speed possible in the first place.
