Back to Blog
4 min read

The Lock You Assumed Was There

You hired someone to build it, so surely the basic locks are on the doors. Usually they are. The trouble is the one time they aren't, because you're the one who finds out. Here's why the security of your site is worth a single direct question, even though it was never supposed to be your job.

Listening · The Lock You Assumed Was There

I took over a client's system from a developer who had moved on, and within an hour I found a door with no lock on it.

Not a weak lock. No lock. By typing a web address into my browser, I could pull up another person's account and change their details. Nothing asked who I was. No password stood in front of it, no login, nothing. Anyone who thought to try the same address would have had the same free run of everyone's information that I did.

Nothing had actually gone wrong yet. No breach, no angry customers, no bad week. That's the unsettling thing about security problems. They look completely fine right up until the moment they very much don't, and the person who finds out is almost never the one who left the door open.

Security is the one part you can't see

Here's what makes this hard for an owner. Nearly everything else about your site, you can look at and judge for yourself. The design looks good or it doesn't. The pages work or they don't. Security is the one area where "looks fine" and "is fine" have nothing to do with each other. A site with no locks on its doors looks exactly like a site with good ones, right up until someone tries a door.

That's why it slips through. Nobody demos the locks. The site works, the customers come in, and the question of whether their information is actually protected never comes up, because there's nothing on the surface to make it come up. The absence of a break-in looks identical to real safety, until it isn't.

Whose job it is, and who pays for it

You're right to feel this shouldn't be your problem. Building the locks is the developer's job, completely. It genuinely is their responsibility to protect the information your customers hand you, and a good one does it without being asked, because it's simply part of building the thing properly — authentication in particular is the part that looks simple and isn't.

But here's the hard part, and it's the same shape as the domain sitting in someone else's account or the code living on a laptop you can't reach. Responsibility and consequence land in different places. When the locks aren't there, the developer who skipped them has usually moved on. You're the one whose customer data leaked, whose name is on the apology, whose business wears it in front of the people who trusted you. Being right about whose fault it was doesn't un-leak anything. The blame is theirs. The fallout is yours. So you check, not because it's fair, but because you're the one who lives with the answer.

What "protected" actually means, in plain words

You don't need to understand how any of this works. It helps to know what it's for, in three plain ideas, so the question you ask has something solid behind it.

There's who can get in, which is about whether the doors have locks at all, the exact thing that was missing in the story above. There's how the sensitive things are stored, especially passwords and customer details, which should be kept in a scrambled form that's useless to anyone who manages to steal a copy — the same instinct behind not keeping your spare key inside the house. And there's keeping the locks current, because security isn't a thing you install once and forget. It's upkeep. Yesterday's good-enough lock is today's known way in, so someone has to keep tending it, and knowing what changed and when is part of how that tending actually gets done. Doors, storage, upkeep. That's the whole shape of it.

The one question, and how to read the answer

You can't test any of this yourself, and you shouldn't try. What you can do is ask one direct question and listen to the texture of the reply.

Ask: how is my customers' information protected, and who's keeping that up to date? A developer who takes security seriously has a real answer and will walk you through it in plain words, glad you asked. One who waves it off, gets vague, or acts like it's a strange thing to want to know has told you something worth knowing. You're not grading the technical detail, most of which you won't follow anyway. You're listening for whether there was a thought behind the locks at all.

You were never supposed to have to ask this. In a fair version of the story, the locks are simply there, and you never once think about them. But you're the one who lives in the building. So it's worth a single question to know the doors are locked, even the doors you'll never walk through yourself.

Share this article

Want to Work Together?

Let's discuss how I can help with your project.

Get in Touch