Logging only allowed fields for JSON

Plugins
1

Currently, Caddy’s structured logging outputs all available fields in the JSON log entries, including many that may not be relevant for a particular use case. This behavior introduces several challenges:

  1. Increased log volume: Logging every available field - including unused or low-value ones - leads to unnecessarily large log files, consuming more disk space and potentially increasing storage costs.
  2. Signal-to-noise ratio: The excess of irrelevant fields makes it harder to extract meaningful insights quickly, especially in production systems where clarity and performance matter.
  3. Security risk and stability concern: Malicious actors could inject large or numerous custom headers, causing logs to balloon in size and possibly impacting system performance or log processing pipelines.

To mitigate these issues, it would be beneficial to introduce a configuration option that defines a whitelist of log fields for JSON logging. This would give users explicit control over which fields are logged, improving efficiency, clarity, and resilience.

A promising direction would be to introduce a feature similar in spirit to caddy-jsonselect-encoder (GitHub - leodido/caddy-jsonselect-encoder: Pick what to log in JSON format), where users can declaratively select the fields they want to emit. For example:

log main {
    output stdout
    format jsonselect "
        {level}
        {ts}
        {logger}
        {msg}
        {size}
        {bytes_read}
        {status}
        {duration}
        {request>remote_ip}
        {request>remote_port}
        {request>client_ip}
        {request>proto}
        {request>method}
        {request>uri}
        {request>headers>Accept}
        {request>headers>Accept-Encoding}
        {request>headers>Content-Length}
        {request>headers>Content-Type}
        {request>headers>User-Agent}
    "
}

Thanks for considering this feature - it would significantly improve logging hygiene and operational flexibility.

2 Likes
2

Copying my answer from where this was repeated on GitHub:

You’re probably looking for: GitHub - caddyserver/transform-encoder: Log encoder module for custom log formats

In general though, we recommend processing logs as a separate step in your infrastructure (unless someone wants to write a Caddy app that does it): How Logging Works — Caddy Documentation

Nothing unique; set a maximum size on headers: JSON Config Structure - Caddy Documentation

1 Like
3

Not quite — we’ve reviewed the transform-encoder module, but unfortunately it doesn’t meet our needs. It outputs plain strings instead of structured JSON, which forces us to manually build JSON-like strings. This is a workaround, not a proper solution. For example:

log main {
	output stdout
	format transform `{\"level\":\"{level}\",\"ts\":\"{ts}\",\"logger\":\"{logger}\",\"ip\":\"{request>remote_ip}\",\"user_id\":\"{user_id}\",\"request\":\"{request>method} {request>uri} {request>proto}\",\"status\":{status},\"size\":{size}}` {
		unescape_strings
	}
}

What’s also confusing is that Caddy already supports a field exclusion (blacklist) mechanism, which shows that the internal logging system is capable of selective field control. But there’s still no support for a whitelist, which has been requested multiple times and repeatedly declined — with no clear explanation.

Adding whitelist support would eliminate the need for custom modules and fragile formatting hacks, and would bring logging configuration in line with common operational requirements — especially when managing log volume, structure, and security.

We hope this can be reconsidered as a native feature.

1 Like
4

I can’t reduce the limit—I need to be able to accept headers of the required size. Requests with near-maximum header sizes are typically rare. But this particular behavior of Caddy could become an attack vector. Some Caddy users may not even be aware of this vulnerability.

5

If someone would like to submit a PR for an allowlist we could review it.