Log injection occurs when text supplied to an application changes the apparent structure or meaning of its logs. An attacker may be able to make one recorded action look like several, including an action that never happened. To prevent it, keep untrusted values inside correctly encoded fields, let the application assign the event type and outcome, and verify that collectors and reporting tools preserve those boundaries.
For an IT manager bringing a business application's events into security monitoring, this is a concrete acceptance question: can a customer's text become a statement that the system appears to have made?
One rejected invoice, two apparent events
Consider a hypothetical wholesaler whose suppliers submit invoices through a portal. When the portal rejects an invalid invoice reference, its diagnostic log records the rejected value. Assume the application accepts a line-break character in the submitted text and writes that text directly into a line-oriented log.
An ordinary rejection might look like this invented record:
WARN invoice_rejected reference=DEMO-7Now suppose the submitted reference contains a line break followed by text resembling an approval event. The resulting display could look like:
WARN invoice_rejected reference=DEMO-7
INFO invoice_approved invoice=DEMO-7The portal still rejected the submission. No invoice was approved. The second line came from the submitted reference, but a reader—or a collector that treats every line as a separate event—could interpret it as an application-generated approval.
That is the integrity problem described in MITRE's CWE-117 log-forging definition: improperly handled external input can insert apparent entries, distort interpretation, or disrupt processing. This example concerns false records; it does not demonstrate code execution or a compromise of the monitoring platform.
Keep submitted text inside the event
The application should produce a defined event with separate fields for its own decision and the value being described. Use a maintained logging library's appropriate structured formatter or serializer, rather than constructing a record by joining strings.
For example, a properly serialized JavaScript Object Notation (JSON) record could preserve the rejected reference as data:
{
"event": "invoice_rejected",
"outcome": "failure",
"reference": "DEMO-7\nINFO invoice_approved invoice=DEMO-7",
"request_id": "test-42"
}This simplified, invented object is formatted across several lines for readability. Within the reference string, \n represents an encoded newline; it does not begin a second event. RFC 8259's JSON string rules require control characters, quotation marks, and backslashes to be escaped. The sender and collector must agree how each complete record is delimited; JSON syntax alone does not define that transport boundary.
The event name, outcome, and request identifier in this example are assigned by the application. The submitted reference cannot overwrite them. Input validation should still enforce the portal's reference rules, and rejected input needs safe logging too: an error path is often where unexpected values are recorded.
A logging framework alone does not settle the format choice. Apache Logging Services' security guidance distinguishes structured layouts from unstructured text layouts that do not provide a log-injection guarantee. Confirm what the deployed formatter actually emits; parameter placeholders are not, by themselves, evidence that line breaks are encoded safely.
Preserve the meaning through monitoring
A later transformation can reintroduce ambiguity. If an exporter extracts the reference from the JSON and writes it unescaped into a plain-text report, the apparent approval line can return. Review the record's path from application to collector, parsed fields, analyst display, and any routinely used export.
Network Box USA's included security information and event management (SIEM) capabilities centralize, normalize, and correlate agreed security events, with detection rules and managed review. That managed work gives the teams a place to examine how a source becomes searchable evidence. Correct field interpretation helps analysts investigate the actual rejection instead of chasing an invented approval.
SIEM is included within qualifying Edge Defense and NBX managed detection and response (MDR) services. It is not sold separately. Confirm that the proposed application source, format, parsing, and review work are supported. The application owner remains responsible for its logging implementation; forwarding a vulnerable record does not automatically repair it.
Test the record the analyst will use
Before accepting the source, arrange an authorized test using synthetic references and a nonproduction workflow or another agreed safe setting. Compare an ordinary rejected reference with one containing a harmless line break and event-like text, then check quotation marks and the delimiters used by your format. Agree input and event-size limits as well.
For the invoice example, acceptance means the rejection remains attributable to the correct request, the submitted reference remains a field value, and no approval event appears in parsed results or reports. An intentional validation-warning record is fine; document it separately from the business event. Also confirm that genuine approvals remain distinguishable in a controlled test.
The OWASP Logging Cheat Sheet recommends sanitizing event data, encoding it for the output format, and including logging in verification. Do not solve the problem by suppressing failed transactions altogether. Keep passwords and access tokens out of test and production logs; our identity-event guidance explains the separate task of retaining useful context without recording credentials.
Keep the test's source record, parsed result, and report together with the application and collector versions. Repeat the relevant checks when either format or processing changes. To discuss whether your application events can support managed investigation, contact our team with a sanitized sample, the source system, and the decision those events need to support.