Secrets are exposed in logs at Information level

I have…

  • Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

I’m submitting a…

  • Regression (a behavior that stopped working in a new release)
  • Bug report <!-- Please search the support forum for a similar before
  • Performance issue
  • Documentation issue or request

Current behavior

When running Squidex in the default configuration (logLevel: Information), the application logs the full environment configuration at startup. This includes sensitive secrets in plain text,

{
  "logLevel": "Information",
  "message": "Application started",
  "environment": {
  }
}

This behavior leads to secrets being exposed in log files, which could be forwarded to external log aggregators.

Expected behavior

Sensitive environment variables should never be logged, regardless of the logging level. At minimum, keys such as _SECRET, *_TOKEN, *_KEY should be redacted or excluded from logs.

A safer alternative would be:

• Redact known-sensitive keys (e.g., replace value with “*****”),

• Or require an explicit flag or opt-in to log full environment details.

Minimal reproduction of the problem

  1. Start a self-hosted Squidex instance with default logging config (logLevel: Information)
  2. Set environment variables that include secrets
  3. Observe startup logs in console/output — secrets appear in plain text

Environment

  • Self hosted with docker
  • Self hosted with IIS
  • Self hosted with other version
  • Cloud version

Version: 7.18.0

Browser:

  • Chrome (desktop)
  • Chrome (Android)
  • Chrome (iOS)
  • Firefox
  • Safari (desktop)
  • Safari (iOS)
  • IE
  • Edge

Others:

I am aware of this. It is known, but I had so much support issues that it was necessary to print the config. I am not sure how to identify the secrets tbh.

Yeah, I totally get it. but, it’s really important to make sure sensitive info doesn’t show up in the logs. In my case, that log ended up in my monitoring system, so I had to rotate all the credentials. I’ve opened a PR—hope you get a chance to check it out!