The Call That Ruins a Monday
A client once called me in a panic. Their developer had left the company months earlier. While cleaning up an old project, someone found the full password to their payment processor sitting in plain text, inside a code file, on a laptop that had since been resold. Nobody knew how many people had seen it. Nobody knew if it had ever been copied.
Nothing had been stolen yet. But the fix took a weekend of emergency work: rotating every password, auditing every transaction, and rebuilding trust with a payment provider that now had questions. It didn't have to happen. The password should never have been typed into the code in the first place.
This is one of the most common mistakes I see in small business software, and it's one of the easiest to prevent once you understand the idea behind it.
The Spare Key and the Blueprint
Here's an analogy I use with clients who have no technical background at all.
Imagine you hire a contractor to renovate your house. You hand them the blueprint: the layout, the wiring plan, the measurements. That blueprint might get copied, shared with subcontractors, emailed to an inspector, or filed away in an office somewhere. That's normal. Nobody worries about it, because a blueprint doesn't get you into the house.
Now imagine you taped your actual spare house key to the back of that blueprint. Suddenly, every copy of the blueprint is also a copy of your key. Every subcontractor, every inspector, every filing cabinet now holds a way into your home.
That's exactly what happens when a password or an API key gets typed directly into a piece of software's code. The code is the blueprint. It gets copied to laptops, backed up, shared with contractors, sometimes even posted online by accident. The password is the key. It should never be taped to it.
What "Hardcoding" a Secret Actually Means
In software, a "secret" is any piece of information that grants access to something valuable: a password, a payment processor key, a database login, an email account credential. "Hardcoding" means a developer types that secret directly into the program's source code, the same file that holds the actual instructions telling the software what to do.
It's often done for a harmless reason. A developer is testing something quickly and just wants it to work, so they paste the real password in to save a step. The trouble is, that file doesn't stay put. It gets saved to a laptop. It gets backed up to a shared drive. It gets sent to a new developer joining the project. It might even get pushed to a public code-sharing site by mistake, which happens more often than most business owners realize. One recent industry report found that tens of millions of passwords and access keys get exposed this way in public code repositories every year, almost always by accident rather than by a break-in.
Once a secret is inside the code, it travels everywhere the code travels. And code travels a lot more than most business owners assume.
Why This Matters More Than It Seems
A leaked password used to require a hacker to break through a locked door. A hardcoded secret skips that step entirely. It's sitting in the open, waiting in a file that dozens of people might touch over the life of a project: developers, contractors, IT support, even automated backup tools. Anyone who ends up with a copy of that code has the key too, whether they meant to or not.
The damage isn't hypothetical. Real businesses have had cloud accounts drained by unexpected charges after a key leaked this way, and payment or customer data exposed after a database password sat in a file that was never meant to leave the building. The fix afterward is always more expensive, and more stressful, than doing it right from the start.
The Safer Way: Keeping the Key Separate
The standard fix is simple in concept: keep the secret completely separate from the code, and load it in only when the software actually runs.
Developers do this with something called an environment variable, a piece of information stored on the server itself, outside any code file, that the software reads at startup. The code says, in effect, "go get the payment key from the server's private settings," instead of stating the payment key out loud. For businesses with more sensitive systems, this goes a step further with a secrets manager, a locked digital vault built specifically to store passwords and keys, hand them out only to the software that's approved to use them, and keep a record of exactly when each one was accessed.
Back to the analogy: this is like leaving your spare key with a locksmith instead of taping it to the blueprint. The contractor still gets into the house when they need to. But the key itself never gets copied, mailed, or filed away by accident.
This also solves a problem beyond leaks. When a password needs to change, and it eventually always does, nobody has to dig through code files hunting for every place it was typed. It gets updated in one place, and every part of the software picks up the new value automatically.
The One Question Worth Asking Your Developer
You don't need to understand the technical details to protect your business. You just need to ask one question: "Where do our passwords and API keys actually live, and are they anywhere inside the code itself?"
A developer following good practice will answer easily and specifically. If the answer is vague, or if secrets are stored the same way the code is, that's worth a closer look. This is a different risk than employees sharing logins with each other, but just as costly, and it connects to how ownership of your source code affects who can see what's inside it.
A five-minute conversation now costs a lot less than a weekend of emergency password rotation later.