Secrets: Keeping Keys Out of the Code

To do its job, Pageturn has to prove who it is to other systems. It needs a password to open its database, and keys to talk to the services that send email or take payments. Without those, the code is just instructions with no way in.

Those passwords and keys are secrets — and the single most important rule about them is that they must never sit inside the code itself. The reason is everything you learned about version control back in Chapter 3: code is shared, copied onto many machines, and stored with its full history, where anyone who can read the project can read whatever is written in it. Where secrets go instead is a small idea with outsized consequences.

Secret storekept outside the code

→

At run timehanded to the app

→

Pageturn runsuses it, never stores it

What a secret is

A secret is a piece of information that grants access: a password, a key, or a token. The exact names vary, but they all do the same job — they prove the holder is allowed in. A password lets Pageturn open its database; an API key lets it use another company's service. Anyone who has the secret can do whatever it unlocks, which is exactly why it has to be guarded.

So a password is one kind of secret, not a different thing from it. When this topic says "keep secrets out of the code," that includes every password, key, and token the app uses.

The mistake: putting secrets in the code

The tempting shortcut is to type the password straight into the code — right there next to the line that opens the database. It works immediately, and that is exactly what makes it dangerous: the problem doesn't show up until later.

Remember what a repository is. The code is shared across the team, copied onto every developer's machine and the build servers, and — the part that really bites — it keeps a full history of every change. A secret written into the code isn't sitting in one private place; it's spread everywhere the repo goes, and recorded in the history forever.

The fix: keep secrets outside

The rule is simple: the secret never goes in the code. Instead it lives somewhere separate and protected, and it is handed to the app only when the app actually runs. The code says "use the database password" without ever containing the password itself — the real value is supplied from the outside at run time.

Teams use a dedicated tool for this, often called a secrets manager — a guarded store that holds secrets and releases them to the app when it starts. You don't need its inner workings yet; the idea to hold onto is the separation. Think of your debit card and its PIN: the card can be seen, photographed, or copied, so you never write the PIN on it — you keep the PIN somewhere else entirely. The code is the card; the secret is the PIN.

Why it matters: history never forgets

A leaked secret is a leaked door. Anyone who finds it can walk straight into whatever it protects — Pageturn's database, its users' data, its payment account — without breaking anything, because they have a valid key.

And here is the catch that surprises people most. If a secret ever does get committed into the code, deleting it later does not make it safe. The repository keeps history, so the old value is still there in the record, readable by anyone who looks back. The only real fix is to change the secret itself — to rotate it, replacing the exposed password or key with a new one so the old one no longer opens anything. This is why secret handling shows up again in the cloud, in CI, and in Kubernetes, and why Security for Beginners returns to it in depth.