PII and Sensitive Data Logging

[roger-mo-gusto]

Is your feature request related to a problem? Please describe.

It's too easy to log PII (personally identifiable information) and sensitive data (for example user emails, names, SSNs, passwords, API keys). I've seen this happen both implicitly with logging out entire request params and payloads and explicitly by logging out things like Rails.logger.info("Operation failed with user #{user.email}").

This can prove to be a compliance concern (GDPR, CCPA, SOC2, HIPAA) and the teams need to then find and redact all the information that leaked into non-PII safe environments.

Rails does have config.filter_parameters, but it doesn't catch the example I added earlier.

Describe the solution you'd like

A PII-Logging cop that catches sensitive data names (a configurable list that includes defaults like email, password, params, etc.) that end up in log-level methods (info, debug, warn, etc.). A configurable list allows teams to add domain-specific fields like bank_account_number and in the forms in which they would generally refer to them e.g., bank_number instead of bank_account_number

Configuration could look like this:

Rails/PiiLogging
  Enabled: pending
  Severity: warning
  SensitiveMethods:
      - email
      - name
      - first_name
      - last_name
      - password
      - ssn
      - token
      - secret
      - api_key
      - phone
      - date_of_birth
    ParamMethods:
      - params
      - to_unsafe_h

This idea started with PII, but I'm thinking a more general name of "sensitive" would be more suitable unless we want to scope this only to PII.

Describe alternatives you've considered

• config.filter_parameters - doesn't apply to explicit log lines.
• Custom cops per repo - works, but doesn't scale well for orgs with multiple repos.
• Repo-level LLM rules - like in CLAUDE.md. Also doesn't scale well.
• Org-level LLM rules - this would be better at catching payloads that get logged either because they're called something other than params or if the author logs something like user.inspect. But this is only gated at the LLM level and despite the push from many engineering organizations' leadership, not 100% of code is written by an LLM.

Additional context

• I suggested it be opt in (Enabled: pending) with a warning severity because while I feel the listed fields aren't likely to result in false positives, they still could
• I'm happy to take a stab at implementing this myself -- would love to contribute for once!

Some references:

• PHI (Protected Health Information): link
• Types of PII: link

Thanks for reading!