Logging for API Security Without Leaking Secrets
Log the signals that catch attackers while redacting tokens, keys, and personal data from your API event stream before it leaks to anyone.
Netbay Cloud Team
Netbay Engineering
On this page
API logs are where you notice the attack — the credential stuffing spike, the anomalous endpoint, the token replay. But logs are also where secrets go to die publicly. A stack trace that prints the full Authorization header, or a debug log that dumps a request body, becomes a permanent record of credentials any operator can read. This post covers logging for security while keeping the sensitive bits out.
What you want in the log
For security analysis you need *metadata about* the request, not the secret payloads. Aim for: timestamp, method, path (not query string), client IP, response status, latency, a request id, and an identified *account/user* — plus enough derived facts (e.g. "failed auth", "over quota") to reconstruct intent. The presence of a header or field is useful; its value rarely is.
The discipline is to log *shape* and *outcome*, never content you would not want in a PR on a public repo.
The classic leaks
- Printing the **Authorization header** or the whole request object via a default logger.
- Logging **URLs with query strings** that carry tokens or API keys.
- Logging full **response bodies** that echo an inserted token back.
- Including **personal data** (email, phone, address) that you neither need nor are cleared to retain.
Untrusted third-party libraries are a common vector here — some frameworks default to verbose request logging on error. Pick loggers with explicit, curated fields and test what they emit on error.
The asymmetry you are fighting is that logs are for operators, but they are written by code that also handles secrets and personal data. That is why the safest model treats the log line as an *audit record with a strict shape*, not a dumping ground. Decide the fixed set of fields an event may carry, and let anything else be dropped or truncated. Content that is genuinely needed for debugging — such as part of a body on a rare parser error — should be sampled, size-capped, and visually truncated with an ellipsis, ideally hashed, so the string that reaches storage is no longer the secret itself even if it looks close. This small transformation converts a common leak into a deliberate, defensible decision.
Redact before you emit
function safeEntry(req, res, dur) {
const auth = req.headers.authorization || "";
return {
ts: new Date().toISOString(),
method: req.method,
path: req.path, // no query string
status: res.statusCode,
latencyMs: dur,
// never include the token value itself
hasAuth: auth.length > 0,
authScheme: auth.split(" ")[0] || "none",
};
}Structured logging with explicit scrubbing
type LogEntry struct {
TS string // ts
Method string // method
Path string // path
Status int // status
Latency int // latency_ms
Account string // account
}
func scrubHeader(h http.Header, name string) map[string]bool {
_, ok := h[name]
return map[string]bool{"present": ok}
}By structuring attributes instead of dumping objects, you forcibly decide what is safe. A key rule of thumb: if a value could ever be a credential, a phone number, or an email, either hash it or omit it entirely. Retaining less is almost always the better failure mode — the cost of re-adding a field you later discover you need is small, while the cost of a leaked secret embedded in months of history is not.
Guardrails to run
- Adopt structured logging with an explicit allow-list of fields.
- Never log full request or response bodies; log statuses and sizes instead.
- Run a redaction layer on an error paths that might dump context.
- Control who can read logs; store them where access is audited, not on the box alone.
- Periodically grep for regex patterns that look like secrets to prove your rule holds.
Takeaway
Log the shape and outcome of requests, redact the sensitive content, and centralize logs behind access control. You get forensic value without making your event stream a credential honeypot. A small VPS on Netbay, from DC01 in Lucknow, is enough to run and audit this pipeline — netbayhosts.in.
Keep reading
Follow along on a real VPS
Deploy Linux in under 60 seconds
These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.
Deploy an instance