Your logs are a database nobody secured

A production database has access controls, audit trails and a change process. Logs derived from it are shipped to a third party, retained for a year, and readable by anyone with a dashboard login.

Whatever ends up in them has effectively been copied to a much less protected place.

Rails filters parameters, and only the ones it knows

Parameter filtering replaces configured keys with [FILTERED]. The default list covers obvious names like password and token.

It matches on name. A field called pw, secret_answer, card, national_insurance or api_key_v2 is logged in full unless you add it.

Worth auditing whenever a form gains a sensitive field, because the failure is silent — nothing warns you that a new parameter is being written to disk in plaintext.

The places filtering does not reach

Exception reporters capture request context by design and are configured separately. Their scrubbing rules drift from your parameter filters over time, so a field filtered from logs can still appear in error reports.

Query logs include bound parameters. Enabling verbose query logging to debug something can write personal data to disk at volume, and it is easy to forget it is on.

Third-party gems log at their own discretion. An HTTP client library logging full request bodies at debug level will happily record an Authorization header.

And your own Rails.logger.info user.inspect writes every attribute, which is a surprisingly common line to find in a codebase.

Anything logged is copied to a system with weaker controls and kept longer than you expect. Decide what belongs there deliberately.

What to log instead

Identifiers rather than values. A user id is enough to investigate; the email address adds nothing operationally and adds a lot to the exposure.

For debugging a sensitive value, log its shape: length, whether it parsed, which validation failed. That is usually what you actually needed.

Correlation ids on every request, so you can follow a request across services without logging its contents.

Retention is a control

The cheapest way to reduce log exposure is to keep less of it for less time. Most logs lose value after weeks, and retention is usually set once and never revisited.

A shorter window reduces both the amount of data at risk and, under most privacy regimes, your obligations about it.

One habit that catches most of it

Periodically grep your own logs for things that should not be there: strings resembling email addresses, card numbers, bearer tokens. It takes minutes and finds the field somebody added last quarter without thinking about it.