Interpreter boundary
Command injection occurs when attacker-controlled data changes the command that an operating-system shell or command interpreter executes. The attacker can add an option, separator, redirection, expansion, substitution, path, or second command. The resulting process runs with the application's operating-system identity and environment.
Argument injection is related. Even without a shell separator, an untrusted value that begins with an option can change the behavior of the selected program.
Avoid the shell
Use a library that performs the required operation directly. Use a filesystem, archive, image, network, or cryptographic API instead of invoking a command-line utility. When a process is necessary, select a fixed executable and pass each argument as a separate value through an API that does not invoke a shell.
Do not construct one command string. Do not rely on a generic escaping function. Shell syntax depends on the interpreter, operating system, quoting context, encoding, environment expansion, and command. A value that is escaped for one layer can be reinterpreted by another.
Constrain execution
Allowlist command choices and argument forms. Reject unexpected options and control length, path, and resource use. Use an absolute executable path and a controlled environment. Run under a dedicated identity with no unnecessary filesystem, network, secret, or administrative access. Apply time, memory, output, and process limits.
Record the fixed operation name, result, duration, and caller context. Do not log secret arguments. Test cancellation and partial output so a failed child process does not leave unsafe state.
Failure and residual risk
A structured process API prevents shell parsing but the invoked program can still interpret an argument as an option, configuration path, URL, template, or plugin. Search-path manipulation can select the wrong executable. Environment variables and inherited file descriptors can carry authority. A sandbox reduces impact but does not make unsafe command construction correct.
Pomerium boundary
Pomerium can protect an administrative route that triggers a server operation. It cannot control how the upstream builds or executes a process. The application must use a fixed operation, safe process interface, validated arguments, and narrow operating-system authority. An authenticated administrator can still submit malicious or mistaken data.
Evaluation checklist
- Can the operation use a library instead of an external command?
- Does the process API avoid a shell and pass each argument separately?
- Is the executable fixed by the server and selected through an absolute path?
- Can an argument be interpreted as an option, path, URL, configuration, or plugin?
- What filesystem, network, credential, and process authority does the child inherit?
- Do tests cover separators, quoting, leading options, alternate encodings, long output, timeout, and cancellation?
