Keeping Secrets Out of Code, Logs and Screenshots

Every software platform depends on secrets: database passwords, keys for payment and email services, tokens for connected accounts and the session data that keeps people signed in. None of them should ever be visible to anyone who does not need them.

The hard part is not storing secrets securely in one place. It is keeping them from leaking into all the other places they tend to wander: source code, configuration examples, logs, error messages, chat conversations, screenshots and support tickets. Here are the habits we follow.

Never in source code

Secrets do not belong in our code repository, not even in a private one, not even temporarily. Code is copied, cloned, shared with tools and kept in history forever. A key committed once lives in that history even after it is deleted from the current file.

Instead, secrets live in protected configuration on the servers that need them, or encrypted in our database where an administrator can manage them through a settings screen. Example configuration files in the repository contain placeholders, never real values.

Encrypted when stored

Where secrets must be stored in the database, such as the credentials a customer uses to connect a source website for an import, they are encrypted before they are saved. They are decrypted only on the server, only at the moment they are needed and never sent back to the browser.

Server-side only

Keys for payment providers, AI services and other platforms stay on the server. The browser never receives them. When a page needs something from an outside service, the browser asks our server, and our server makes the call with its own key. Public identifiers that are designed to be visible, such as a payment form's publishable key, are the only exception, and they cannot be used to act on an account.

Not in logs or errors

Logs are written constantly and read by many people and tools. We avoid logging request bodies that might contain passwords, tokens or card details, and we keep error messages shown to people generic. When something fails, the useful technical detail goes to a log that is reviewed by our team, with sensitive values left out.

Not in chat, prompts or screenshots

Modern work happens in chat tools and with AI assistants. Those are some of the easiest places for a secret to leak, because pasting a key "just for a second" feels harmless. Our rules are explicit: passwords, keys and session cookies are never pasted into conversations, prompts, commands, memory notes or handoff documents. If a screenshot shows a secret, it is not shared, and the secret is treated as exposed.

That last point matters. When a secret might have been seen by someone who should not have it, the safe response is to rotate it: replace it with a new one and retire the old one. Rotation is cheaper than hoping.

Credentials vaults for people, not files

When a person or an automated tool needs a credential to do approved work, it comes from a proper credential vault, retrieved by the tool at the moment of use, not from a text file on a desktop. Assistants and tools never print the value; they only use it.

Least privilege for every key

A key that can do everything is a disaster when it leaks. We prefer keys scoped to the job: a key that can update DNS for one zone rather than an entire account, a token that can read rather than write. When a provider offers narrower permissions, we use them.

A culture, not a checklist

Tools help: scanners can catch secrets in code before it is pushed, and frameworks can hide sensitive fields in logs. But the real protection is a shared habit. Everyone on the team, and every assistant that works with us, treats secrets as radioactive: handled only when necessary, never copied for convenience and replaced when in doubt. It is part of the same care described in failing closed and a hidden button is not security.

Frequently asked questions

What should I do if I accidentally share an API key?

Rotate it immediately: create a new key, update the systems that use it and revoke the old one. Assume an exposed key has been seen.

Is it safe to store passwords in a private repository?

No. Repositories are copied and kept in history, so a password committed even once can resurface. Use protected configuration or a credential vault instead.

Why are some keys visible in a website's code?

Some services provide public keys designed to be visible, such as a payment form's publishable key. They identify an account but cannot perform sensitive actions on their own.