Injection Vulnerabilities

Data becomes structure

Injection occurs when an application combines attacker-controlled data with the syntax of a command, query, template, expression, or document and the receiving interpreter treats part of that data as structure. Examples include SQL, operating-system command, LDAP, expression-language, template, log, and header injection.

The key defect is not the presence of one special character. The defect is failure to preserve the boundary between data and instructions.

Attack path

An attacker controls a value. The application transforms or concatenates it into interpreter input. The interpreter parses the combined value with more authority than the attacker should have. The result can read or change data, run code, alter control flow, reach another service, or corrupt an audit record.

Trace the input through decoding, normalization, validation, storage, retrieval, template expansion, and the final sink. Stored data can become an injection payload later. A value that was safe for HTML text can be unsafe when reused in JavaScript or a shell command.

Prevention hierarchy

First, avoid the interpreter or dynamic feature. Use a structured library call instead of a shell. Second, use a typed or parameterized interface that sends structure and data separately. Third, constrain any structural choice, such as a sort column, to a fixed allowlist. Fourth, apply context-specific encoding only when the interpreter defines a safe encoding for that position.

Run the interpreter with narrow authority. A parameterized query can prevent SQL injection but an overprivileged database account still increases the impact of another defect. Add tests for boundary values, stored payloads, alternate encodings, second-order use, and each interpreter context.

Failure and residual risk

Escaping is easy to apply in the wrong context or before a later decode. A web application firewall can block known patterns but cannot prove that structure and data stay separate. Input validation can reduce malformed data but cannot safely make arbitrary string concatenation into a command. Generic denial messages can hide a successful side effect from a weak test.

Pomerium boundary

Pomerium can restrict who reaches a route and can protect administrative tools from anonymous access. It does not inspect the application code that constructs SQL, commands, templates, or expressions. An authenticated or compromised user can still supply an injection payload. The application must use safe interfaces and narrow downstream authority.