Problem description

We encountered an issue in production when using Npgsql together with OpenTelemetry.

With the Persist Security Info=true option enabled, we observed that the database password may be exposed in telemetry data — specifically in the span attribute db.npgsql.data_source.

How this manifests in practice

• The value of db.npgsql.data_source is derived from data source / connection pool information.
• When Persist Security Info=true is enabled, these values may include the password.
• OpenTelemetry instrumentation for Npgsql is applied globally at the process level.
• Third-party libraries (for example, job schedulers, background processing frameworks, etc.) may extract or reuse the connection string or related identifiers from an already created NpgsqlConnection.

Why existing mitigations are insufficient

Formally, Npgsql provides a way to override or customize connection pool names. However, in real-world services this does not always solve the problem:

• the owning service often does not control how third-party libraries construct or propagate connection-related strings;
• as a result, it cannot reliably guarantee that such values are masked before reaching telemetry.

Security impact

This can lead to a situation where the database password is exported in clear text into distributed tracing systems, which are typically accessible to a much wider audience than secret storage systems. From a security perspective, this represents a serious risk.

Expected behavior and proposed direction

We believe that in such scenarios mandatory sanitization of sensitive data is required at the Npgsql / instrumentation level:

• sanitization should apply to telemetry data (tracing);
• a similar approach should be used for logging and metrics;
• at the same time, sanitization must not break legitimate scenarios where a full connection string is required for third-party services or libraries inside the process.

In other words, we are not proposing to prohibit or change the behavior of Persist Security Info itself.

We expect that:

• inside the process, the connection string may be available in full when explicitly allowed;
• but any data leaving the process boundary (telemetry, logs, metrics) must be strictly protected from secret leakage.

Why this is unexpected

The current influence of Persist Security Info on telemetry output is surprising. Historically, this option is understood as controlling access to sensitive information through the connection API, not as a flag that permits exporting secrets into external observability systems.