Secure Logging: Preventing Secrets from Leaking into Logs

Your application may be leaking credentials without anyone realizing it.

A single debug statement that logs an HTTP request, headers, or an exception can put API keys, passwords, access tokens, session cookies, and other sensitive information into your logs.

The dangerous part?

The developer may never have explicitly logged the secret.

For example:

logger.debug("Request headers: %s", headers)
logger.debug("Request body: %s", request.json())

These look like ordinary debugging statements. But if the request contains:

{
  "username": "admin",
  "password": "MySecret123",
  "api_key": "abc123..."
}

the entire secret may now be sitting in a log file.

And logs are rarely confined to one machine. They may be shipped to centralized logging platforms, retained for weeks or months, backed up, indexed, and made accessible to developers, operations teams, and monitoring systems.

A secret that was supposed to remain inside the application has now become part of your logging infrastructure.

Don't rely only on developers

The usual advice is simple: Don't log secrets.

That's necessary, but it isn't sufficient.

Modern applications have multiple components generating logs:

Proxy → Web Server → Application → APIs → Database → Messaging

There may also be middleware, SDKs, exception handlers, and third-party libraries.

Eventually, someone may log more data than intended.

A better approach is to add secret detection and redaction at the logging layer.

Redact secrets automatically

A logging filter can inspect every message before it reaches the log destination.

For example:

Authorization: Bearer eyJhbGciOi...

can become:

Authorization: Bearer [REDACTED]

Similarly:

AWS_ACCESS_KEY_ID=AKIA...

can become:

AWS_ACCESS_KEY_ID=[REDACTED]

This can be implemented using a combination of pattern-based and field-based detection.

Pattern-based detection

Regular expressions can identify recognizable formats such as:

• JWTs
• Cloud credentials
• Private keys
• Bearer tokens
• Database connection strings

Field-based detection

Structured logs can be inspected for sensitive field names such as:

password
secret
api_key
access_token
refresh_token
authorization
cookie
private_key

Their values can then be replaced with [REDACTED].

Implementing this in existing logging frameworks

You don't necessarily need to replace your logging framework.

The redaction layer can be added to frameworks such as Log4j2 and Python's standard logging framework.

Log4j2

Log4j2 provides a RewriteAppender mechanism that can modify a LogEvent before it is passed to another appender.

A custom RewritePolicy can inspect log messages and replace sensitive patterns before the event reaches the actual log destination.

Conceptually:

Application
     ↓
   Log4j2
     ↓
Rewrite / Redaction Policy
     ↓
 Write to File / Console / Log Platform

Python logging

Python's standard logging framework supports filters that can modify a LogRecord before it is emitted.

A simple filter can apply regular expressions to log messages:

class SecretRedactionFilter(logging.Filter):

    patterns = [
        (
            re.compile(r"Bearer\s+\S+"),
            "Bearer [REDACTED]"
        ),
        (
            re.compile(r"AKIA[0-9A-Z]{16}"),
            "[AWS_KEY_REDACTED]"
        ),
    ]

    def filter(self, record):
        message = record.getMessage()

        for pattern, replacement in self.patterns:
            message = pattern.sub(replacement, message)

        record.msg = message
        record.args = ()

        return True

The important point is that existing application logging statements don't necessarily have to change.

A simple defense-in-depth model

Application
     ↓
    Logger
     ↓
Secret Detection
     ↓
Redaction
     ↓
  Log Store

Additional controls can include:

• Secret scanning in Git/CI
• Periodic scanning of logs
• Restricted access to production logs
• Appropriate log retention
• Credential rotation if a real secret is exposed

The key principle

Don't assume that developers will never accidentally log sensitive information.

Assume accidental logging will happen, and make the logging infrastructure safe by default.

Secure logging isn't only about what developers choose to log.

It's also about what the logging system allows to reach the logs.