Audit logs that help investigations without collecting secrets

The Dual Mandate of Security Logging

Application logging provides contextual insight that infrastructure logging alone cannot match. The application possesses direct knowledge of the user identity, their roles, and the specific business logic context of an event. Consequently, applications serve as the primary source of truth for security incident investigations.

However, this proximity to user data introduces significant risk. Applications routinely handle highly sensitive information, and routing this data blindly into centralized logging systems violates data minimization principles and regulatory requirements. Engineers must design logging pipelines that aggressively filter and redact sensitive fields before they ever touch a persistent storage volume, ensuring that logs remain useful for debugging and threat hunting without becoming a lucrative target for attackers.

High-Value Event Targets

To maximize investigative utility while avoiding alarm fog, logging efforts should focus on specific, high-value security events. The OWASP Logging Cheat Sheet emphasizes the necessity of recording authentication successes and failures, as these provide critical early indicators of credential-based attacks like credential stuffing and password spraying.

Other mandatory events include input validation failures, authorization denials, and session management anomalies. When recording these events, the logging payload must consistently capture the who, what, when, and where. This includes the event timestamp, the application identifier, the source IP address, and the specific user identity if known. Capturing this structured context enables security teams to correlate related events across distributed microservices during an active incident.

• Authentication events: Log both successes and failures to establish baselines and detect brute-force activity.
• Validation failures: Record protocol violations and unacceptable encodings without storing the raw malicious payload intact.
• High-risk functionality: Audit actions such as user administration, access to payment data, or the use of default break-glass accounts.
• System anomalies: Track deserialization failures and backend TLS certificate validation failures.

Data Exclusion and Sanitization Requirements

Certain classes of data must never be recorded directly in application logs. According to OWASP guidelines, applications must actively remove, mask, sanitize, hash, or encrypt specific sensitive fields prior to emission.

If a field is malformed or contains unexpected characters, the application should omit or safely replace that specific field and record the validation failure with bounded, safe context. Dropping the entire security event destroys evidence, while logging the raw malformed input invites log injection attacks. Developers must apply strict sanitization on all event data to neutralize carriage return and line feed characters.

• Session identification values: Replace with securely hashed values if tracking session-specific events is required.
• Authentication credentials: Passwords, API keys, and access tokens must be unconditionally dropped.
• System secrets: Exclude database connection strings, encryption keys, and internal network addresses.
• Sensitive PII: Redact government identifiers, payment card holder data, and health information.

Concrete Worked Example: Authentication Redaction

Consider a hypothetical authentication microservice processing a login request. The incoming HTTP request contains a username, a plaintext password, and a device fingerprint. A naive logger might dump the entire request object, exposing the password.

A secure logging implementation intercepts the request payload, applies a defined redaction schema, and emits a sanitized JSON object. The resulting synthetic log fixture demonstrates this approach: the 'password' field is replaced with the literal string '[REDACTED]', the 'sessionId' is replaced with a SHA-256 hash of the actual identifier, and the 'username' is retained for investigative correlation. The log also includes the source IP, the event type, and an interaction identifier to link subsequent actions.

Safe Test Matrix for Redaction Filters

To ensure redaction mechanisms function correctly under various conditions, engineering teams must validate their log formatters against a strict test matrix. The following matrix outlines hypothetical synthetic inputs and their expected allowed or denied outcomes within the emitted log payload.

• Input: valid username 'admin_user' -> Outcome: Allowed, logged as 'admin_user'.
• Input: password field containing 'Hunter2' -> Outcome: Denied, logged as '[REDACTED]'.
• Input: session token 'eyJh...' -> Outcome: Denied, logged as hashed value 'a1b2c3d4...'.
• Input: username containing newline characters '\nadmin' -> Outcome: Denied, logged as sanitized string '\\nadmin' or omitted.
• Input: malformed JSON payload in request body -> Outcome: Allowed, logged as a generic parsing error event with raw payload dropped.

Implementation Tradeoffs and Failure Modes

Implementing aggressive log redaction introduces performance and operational tradeoffs. Heavy reliance on complex regular expressions to identify sensitive data like credit card numbers or social security numbers can cause severe CPU bottlenecks, especially in high-throughput applications. Deny-list redaction approaches are notoriously fragile; when developers add new fields to a data model, those fields may bypass the redaction filter and leak secrets until the filter is updated.

An allow-list approach, where only explicitly approved fields are serialized to the log output, is much safer but requires rigorous maintenance. Furthermore, failures in the logging system itself must not cascade to the core application logic. Logging should fail open operationally, but fail closed security-wise, meaning if the redactor crashes, the raw data must not be emitted.

Evidence Limits and Operational Constraints

While audit logs are essential, they possess explicit evidentiary limits. Application logs are generated by software running in a specific trust zone; if the underlying host is compromised, the integrity of the logs generated during the intrusion is suspect. Logs sent to remote storage can be delayed, dropped, or intercepted if not transmitted over secure channels.

Additionally, logs struggle to establish true non-repudiation. The trustworthiness of a log entry relies heavily on the proper auditing of the logging party, rather than inherent cryptographic proof. Unexpected inputs recorded in logs should be treated as suspicious events requiring correlation, not as definitive proof of an intentional attack, as client defects or user misuse frequently generate identical signatures.

Sources

Factual claims regarding logging practices, redaction requirements, and sanitization are grounded in the OWASP Logging Cheat Sheet.

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

Drafted with Gemini and checked for source links, advisory identifiers, structure and unsupported product claims. Examples are synthetic and are not scan results.

• OWASP Logging Cheat Sheet