[Logger] Redact sensitive information from logs

[rsamoilov]

Description

Rage's structured logging system makes it easy to add context to log entries using key-value pairs. However, there is currently no built-in mechanism to prevent sensitive information — such as passwords, tokens, credit card numbers, or personal data — from being written to logs.

For example, a developer might accidentally log sensitive data through with_context or append_info_to_payload:

Rage.logger.info "user signed in", email: user.email, token: session_token

Or sensitive parameters might leak through request logs if a controller doesn't properly filter them.

A redaction setting would allow users to define matching rules for keys whose values should be automatically replaced with [REDACTED] (or similar) before the log entry is written.

Example:

Rage.configure do
  config.logger.redact_keys = [:password, :token, :secret, :authorization, :credit_card]
end

Since Rage logs are structured as key-value pairs, the implementation boils down to iterating the log context and replacing values for matching keys. The more interesting design question is how the matching rules should work.

Design considerations

• Exact vs. pattern matching. Should keys match exactly (:password matches only password) or should they support substring/pattern matching (:password also matches password_confirmation, old_password, etc.)? Substring matching is more forgiving but could produce false positives. Consider whether the default should be substring matching with an option for exact matching, or vice versa.
• Nested keys. If log context contains nested hashes (e.g. { user: { email: "...", password: "..." } }), should redaction apply recursively? This adds complexity but is important for safety.
• Custom matchers. Beyond key names, some use cases require value-based redaction (e.g. redacting strings that look like credit card numbers regardless of the key name). Consider whether custom matcher procs should be supported in the initial implementation or deferred to a follow-up.
• Request log integration. Redaction should apply consistently across all log entry points — Rage.logger.info with context, append_info_to_payload, global log_context.
• Performance. Redaction runs on every log entry, so the matching logic should be fast.

Tips

• Review the Logging docs to understand how structured logging, with_context, append_info_to_payload, and external loggers work.
• Look at how Rage::Logger#rebuild! and Rage::LogProcessor#rebuild! use dynamic code generation — this may be a good place to integrate redaction logic efficiently.
• Check the architecture doc to see how Rage's core components interact and to understand the design principles.
• Read the contributing guide for coding conventions and design principles used across the codebase.
• Before starting the implementation, please share your proposed design approach. The matching rules for keys need careful designing, so discussing the approach early will drastically increase the chances of acceptance and help avoid rework.
• Feel free to ask any questions or request help in the comments below!

[RedZapdos123]

I analyzed the current logger flow. My idea is to implement this as a deterministic key based redaction instead of structured log data.

The Plan:

• Add configurable redact_keys, normalized once to downcased strings.
• Match keys exactly and case insensitively, so :token and "token" behave the same;.
• Redact recursively inside nested hashes and arrays.
• Apply the same redaction helper in the centralized logger path so it covers with_context, inline logger context, append_info_to_payload, config.log_context, and dynamic external logger payloads consistently.

I think substring matching or value based scanners may not be used here. Exact key matching keeps the behavior predictable and avoids false positives.

For dynamic external loggers, should redaction also apply inside request_info (like request_info[:params]) or only to the structured context?

[rsamoilov]

Add configurable redact_keys

Any specific reason you don’t want to use Rails’ filter_parameters?

Exact key matching keeps the behavior predictable and avoids false positives.

I was also leaning towards exact matching, but with this functionality we need to worry more about false negatives. What do you think about Rails-style substring matching instead?

For dynamic external loggers, should redaction also apply inside request_info (like request_info[:params]) or only to the structured context?

I’d say only the context.

[RedZapdos123]

Okay. I will scope this to structured context only and use the matching to Rails style partial matching so it catches keys like password_confirmation and api_token.

Should it reuse ActiveSupport::ParameterFilter directly or just follow the same matching behavior in Rage’s own logger code?

[rsamoilov]

Should it reuse ActiveSupport::ParameterFilter directly or just follow the same matching behavior in Rage’s own logger code?

It should follow the same matching behavior in Rage's own logger code. The framework code (with few exceptions) can't rely on Active Support methods.

[RedZapdos123]

Opened the PR #386.
It adds config.filter_parameters with Rails style case insensitive partial matching for structured log context, implemented in Rage’s logger code. It covers with_context, inline context, request log context, and dynamic external logger context, while keeping request_info unchanged.