CloudlessKit / Guides

How to scrub logs and config files before sharing

Updated July 22, 2026

A stack trace from your own app can carry an API key straight out of an Authorization header, without a single line of your code ever printing it on purpose. A HAR file exported from your browser's Network tab carries a copy of every cookie your browser sent while recording, including the one currently keeping you logged in. Neither looks dangerous at a glance, which is exactly why both keep turning up in support tickets, GitHub issues, forum threads, and pasted straight into AI chatbots.

Where the leaks tend to hide in a normal log dump

Most people scan a log for the error message and skip past everything around it. That's the problem: the interesting line is rarely the dangerous one.

Request headers are the biggest offender. An Authorization: Bearer eyJ... line, an X-Api-Key header, or a plain Cookie: header sitting three lines above the stack trace you actually wanted to share is a working credential, not a debugging artifact. Stack traces themselves often print the logged-in user's email address, sometimes a full name if it's part of a serialized session object, and internal hostnames like db-primary.internal.corp or a private IP range that tells an outsider more about your network layout than they need. Support engineers see this constantly: a customer forwards "the whole error," and the whole error includes their account email, their session token, and the internal service name that handled the request.

The HAR file trap

If someone on a support team has ever asked you to "export a HAR file and attach it," you've probably done it without thinking twice. A HAR (HTTP Archive) file is just a JSON dump of everything your browser's Network tab recorded: every request, every response, and every header on both sides. That includes the Authorization header on your API calls and the Cookie header on every single request your browser made while you were recording, session cookie included.

That's the trap. A HAR file isn't a neutral trace of "what happened." It's closer to a temporary copy of your login session, packaged as a downloadable file. Attaching it to a private, access-controlled support ticket is usually fine. Attaching it to a public GitHub issue, a vendor's public forum, or pasting its contents into a chatbot hands over live credentials, sometimes ones that stay valid for hours or days after you exported the file.

JWTs look encrypted but they aren't

A JSON Web Token looks like noise: three chunks of random-looking characters separated by dots. The middle chunk, the payload, is just base64-encoded JSON. No key and no password are needed to read it. Anyone can paste it into any JWT decoder, or decode the base64 chunk by hand, and see exactly what's inside: a user ID, an email address, account roles, an internal tenant name, expiry timestamps, sometimes more detail than the app itself shows anywhere in its own interface.

If a JWT shows up in a log you're about to share and the bug has nothing to do with the token's contents, cut it out entirely rather than trust that a stranger won't bother decoding it.

It takes them about five seconds.

Don't paste the whole .env file

This one is common and almost always avoidable. Someone hits a config problem, and instead of pointing to the one line that's wrong, they paste the entire .env file into a ticket or issue "for context." That file usually holds a database password and a session signing secret, plus API keys for whatever third-party services the app talks to, all sitting in one place.

The fix is simple: paste the specific line or two that's actually relevant, and replace the value after the equals sign with something like REDACTED or a short note on what kind of value it is. If you genuinely need to show the shape of the whole file, to prove a variable is missing, say, list the variable names only and drop every value.

Why consistent placeholders work better than blacking everything out

It's tempting to just black out anything sensitive and call it done. The problem is that whoever reads your scrubbed log still has to debug something, and a wall of identical [REDACTED] markers throws away information they need, like whether two different requests reused the same token or whether two "different" errors are actually the same session hitting the same failure twice.

A consistent placeholder solves this without exposing anything real. If every occurrence of one specific email address always becomes the same tag, say EMAIL_1, and a different email becomes EMAIL_2, the log stays fully readable for debugging while the actual values never leave your machine. Doing this by hand with find-and-replace works fine for one obvious secret in a short log. It falls apart once you're scrubbing a few dozen scattered tokens across a multi-thousand-line file, especially when the same value shows up truncated, wrapped across a line break, or with different casing.

PII Redactor defaults to exactly this behavior: it finds emails, API keys, tokens, and similar values in pasted text or a dropped .txt, .log, .json, .csv, .env, or .har file, and replaces each one with a consistent placeholder so you can still tell which lines are related, all running in your browser with nothing uploaded. It only handles text-based formats, though. If what you're sharing is a PDF export of a log, PDF Toolkit's redact tool works directly on that file instead. For a screenshot, crop or black out the sensitive parts in any image editor before it leaves your machine.

A checklist before you paste

Run through this before dropping a log into a ticket, issue, forum post, or chat window:

• Strip or blank Authorization, Cookie, and Set-Cookie headers first, before anything else.
• Search the file for .env-style KEY=value lines and cut the value, not just the ones that look obviously sensitive.
• Decode any JWT you see before deciding whether to keep it. If you don't need its contents, delete it rather than trust nobody will look.
• Check stack traces for internal hostnames and private IP ranges; they tell an outsider more about your infrastructure than the bug report needs.
• If it's a HAR file, ask whether you actually need the full export or just a screenshot of the one failing request.
• Confirm where the log is going. An internal ticket in your own company's tracker carries less risk than a public GitHub issue or a message pasted into a public forum, and a public post tends to get cached and archived somewhere you don't control.

A tool like this doesn't replace judgment. A quick manual scrub of one obvious secret in a five-line error is fine to do by eye. It's the logs nobody reads carefully, the ones that are ten screens long and get forwarded three times, where a consistent, repeatable pass matters most.