PII redaction and log injection

A team completes their SOC 2 audit. The auditor finds raw email addresses and auth tokens in three months of indexed log storage. The logs were never flagged as a data store. The remediation takes six weeks and costs more than the original logging infrastructure.

Why logs are a PII risk

Logs are generated in the hot path of every request. They accumulate request bodies, headers, database queries, stack traces — any of which can carry sensitive data if the engineer was not deliberate.

Common PII patterns found in real incidents: full request bodies including Authorization headers and session tokens, email addresses logged as userId context, phone numbers in user-submitted form fields, raw SQL queries containing user input, stack traces with object dumps that include customer records.

The problem compounds: logs are retained for weeks or months, replicated to cold storage, and readable by a much wider audience than the primary database. A breach of the log backend exposes data that was never intended to live there.

Redaction at the source

The logger SDK is the right first line of defence. Every major production logger supports a deny-list that strips known-sensitive paths before serialization:

• pino (Node.js): redact option takes an array of dot-notation paths (['req.headers.authorization', 'body.password', 'user.email']). Pino replaces the values with [Redacted] before writing. Overhead: approximately 2 ms per 1,000 messages for 5 fields.
• log4j2 (JVM): pattern converters and Rewrite appenders can strip fields by key name.
• structlog (Python): a processor in the processor chain can strip or hash sensitive keys before rendering.
• slog (Go): a custom Handler wraps the base handler and filters attributes before writing.

Static redaction (known field paths) is cheap. Dynamic redaction (regex over the full message body) is 4-10x more expensive and should be reserved for unstructured fields where you cannot enumerate the paths in advance.

Defence in depth: the collector tier

Application-level redaction catches the deliberate paths. The collector tier catches what the application misses — third-party libraries that log request objects, errors that serialize unexpected context, or a new service that has not yet adopted the per-org wrapper logger.

The OTel Collector, Fluent Bit, and Vector each support redaction processors that run regex patterns over log record attributes before shipping. The pattern: strip known PII formats (email addresses, phone number patterns, credit-card-like sequences) on every line regardless of field name. This adds latency to the collector pipeline (20-50 µs per line for a 5-pattern set) but runs off the critical application path and is worth the cost.

Production rule: deny-list at the source for known fields; regex scrubber at the collector as the safety net. Never rely on the log backend’s own masking as the first or only layer — by then the data has already left the host.

Log injection: the security failure-mode

Log injection (CWE-117) occurs when user-supplied input is concatenated or interpolated into a log message without sanitization. Two attack shapes:

Newline injection: the input contains a literal newline. A log line such as INFO: received comment: <user input> splits into two lines when the input embeds a newline followed by a crafted payload — ERROR: admin user X deleted production database. Downstream parsers, SIEM rules, and audit-trail consumers treat both lines as real records. Audit-trail manipulation is the textbook scenario.

JSON structural injection: in JSON output, if user input is concatenated into a string field without escaping — rather than being passed as a value to the JSON serializer — special characters can close the current string and inject new key-value pairs, corrupting the log record and potentially bypassing SIEM filters that rely on specific field values.

The Log4Shell vulnerability (CVE-2021-44228, December 2021) was a related but distinct failure: log4j2’s message lookup feature treated log message content as a template, allowing JNDI lookups in user-controlled strings to trigger remote code execution. The lesson generalizes: log message content is an input surface.

Prevention is structural: never interpolate user input into log message strings. Always pass user input as a typed field attribute, letting the JSON serializer handle escaping:

// Vulnerable — user input in message string
logger.info(`received comment: ${req.body.comment}`);

// Safe — user input as a typed field
logger.info({ event: "comment_received", comment: req.body.comment }, "comment received");

The serializer escapes the field value, making injection structurally impossible regardless of what the input contains.