Observability

Secret redaction

Server logs can silently echo secrets — a DB driver error that interpolates a connection string, an app error whose message contains a token, or a caller passing { password } into the logger. The redaction layer masks values shaped like secrets before anything reaches the log sink or audit trail.

What gets redacted

The redaction operates at two levels: string scanning and object walking. Together they cover the common ways secrets appear in log data:

Bearer and Basic tokens — any instance of Bearer <value> or Basic <value> in a string is replaced with Bearer [REDACTED].
Authorization headers — inline Authorization: <value> or auth=<value> patterns.
URI userinfo — credentials in URLs like https://user:pass@host become https://user:[REDACTED]@host.
Sensitive key names — any object key matching password, token, secret, api_key, private_key, authorization, session, credential, or bearer has its entire value replaced with [REDACTED].

redactString — scanning plain text

Use redactString on error messages, log messages, or any string that might contain an embedded secret:

redacting error messages

import { redactString, REDACTED } from "@thexjs/core";const safe = redactString(  "Authorization: Bearer sk-abc123def456, connection via https://admin:hunter2@db.example.com");// "Authorization: Bearer [REDACTED], connection via https://admin:[REDACTED]@db.example.com"const noop = redactString(  "User 42 updated their profile picture");// unchanged — no secret patterns detected

redactValue — sanitizing objects

When logging structured data, wrap the object with redactValue. It walks the object tree recursively, redacting both string values (via redactString) and values under sensitive keys:

redacting log payloads

import { redactValue } from "@thexjs/core";const payload = {  userId: "user_abc",  password: "s3cret!",  metadata: {    token: "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0",    error: "Connection refused — Bearer sk-abc123",  },};const safe = redactValue(payload);// {//   userId: "user_abc",//   password: "[REDACTED]",//   metadata: {//     token: "[REDACTED]",//     error: "Connection refused — Bearer [REDACTED]",//   },// }

Checking key names

The isSensitiveKey function lets you check whether a given key name would be treated as sensitive. This is useful when building custom log sanitizers:

key inspection

import { isSensitiveKey } from "@thexjs/core";isSensitiveKey("password");           // trueisSensitiveKey("api_key");            // trueisSensitiveKey("access-token");       // trueisSensitiveKey("Authorization");      // trueisSensitiveKey("name");               // falseisSensitiveKey("email");              // false

Where redaction is applied automatically

You don't need to call these functions for most cases — the framework applies them internally:

The audit trail passes every entry's reason through redactString and all metadata values through redactValue.
The tracing layer passes database statements through redactString and masks quoted literals before recording them as span attributes.
The logger's internal formatter applies redactValue to every structured field before serializing the JSON log line.

Observability