Security Basics Every Client Should Ask About

Security tends to become a priority right after a breach. Before that, it's easy to assume your developer is handling it, your hosting provider has it covered, or your software is too small to be a target. None of those assumptions hold up under scrutiny.

I work with clients who are smart, capable people in their fields — musicians, label managers, venue operators, academics — who aren't software engineers and don't want to be. They hire me to build and maintain software so they don't have to think about it. But there are a handful of security questions that every client should be asking, regardless of their technical background. Not because they need to understand the implementation, but because the answers tell you a lot about how seriously your developer takes their work.

Who has access to what?

This sounds obvious, but it's frequently overlooked. Ask your developer: who has credentials to your production environment? That includes the database, the hosting dashboard, any third-party services connected to your app, and your DNS provider.

Credential sprawl is one of the most common security problems I see in software that's been around for a few years. A contractor worked on something two years ago and still has access. A staging environment uses the same database password as production. An API key got committed to the git history and was never rotated.

The answer you want is: a short list of named individuals, with access scoped to what they actually need. If your developer can't tell you who has access, that's a problem worth addressing before anything else.

Are secrets stored securely?

Passwords, API keys, database credentials — these are secrets. They should never be hardcoded into source code or committed to version control. They should live in environment variables or a secrets manager, separate from the application code itself.

This matters because code repositories change hands. Code gets forked, shared, archived. If a secret is baked into your codebase and that code ever leaves the hands of people who are supposed to have it, the secret is compromised — and you may never know.

When I build something like Composer Catalog, every credential that touches the live database or third-party APIs lives in environment variables, never in the code. It's a non-negotiable practice. Ask your developer where their secrets live. If the answer is vague, push for specifics.

What's the plan if something gets compromised?

Nobody wants to think about this, but a developer who hasn't thought about it is one you should be nervous about. Ask: if a server gets hacked, or a credential leaks, what happens next?

You're not asking for a 20-page incident response plan. You're asking whether there's a backup. Whether there's monitoring that would even detect unusual activity. Whether someone knows what to do if the worst happens.

The things that reduce damage in a real incident are almost all set up in advance: automated backups with tested restore procedures, alerts when something looks wrong, clear ownership of who takes action. If your developer shrugs at this question, that's useful information.

Is data encrypted in transit and at rest?

This is a two-part question. In transit means: when someone's browser communicates with your server, is that connection encrypted? The answer should be yes, and it should be enforced — not just available but required. HTTPS everywhere, no exceptions.

At rest means: if someone gets access to your database files directly, is the data readable? For most apps, this comes down to whether sensitive fields like passwords are hashed (not stored as plain text) and whether the database itself sits behind proper access controls.

For applications that handle any kind of user data — even something as low-stakes as a contact form that stores email addresses — these aren't advanced features. They're table stakes. The bar isn't high, but a surprising number of projects are built without clearing it.

How are dependencies managed?

Almost every modern web application is built on top of open-source libraries and frameworks. That's fine — it's efficient and there's no reason to reinvent everything. But those dependencies have their own security histories. They get vulnerabilities discovered in them. They need to be updated.

The question to ask is: how does your developer keep track of what's in your project and whether any of it has known vulnerabilities? Tools exist that scan your dependencies automatically and flag issues. It takes a few minutes to set up and runs continuously.

What you don't want is a project that was built three years ago, never updated, and is still running a version of something with a publicly documented exploit. That happens more than you'd think, especially with projects that are considered "done" and handed off.

Is there logging and monitoring?

If something goes wrong — a failed login flood, unexpected data access, an error in a payment flow — how would anyone know? The answer depends on whether your application logs meaningful events and whether anyone reviews those logs.

I'm not suggesting every small project needs a security operations center. But basic application logging, combined with alerting on errors or unusual patterns, is something that should exist. At minimum you want to know when something breaks. Ideally you want to know before your users tell you.

For client projects I maintain, I have monitoring that notifies me when things go wrong, so I'm usually aware of issues before a client even notices them. That's not magic — it's just having set up alerts.

The honest bottom line

Most security problems in small and medium software projects aren't sophisticated. They're the result of things never being set up properly in the first place: credentials not rotated, access not reviewed, backups not tested. The good news is that fixing these things isn't expensive or complicated. It mostly requires someone to care enough to do them.

Asking these questions doesn't make you a difficult client. It makes you someone who's paying attention. A developer who's doing the work well will answer these questions easily, because they've already thought about them. That's the response you're looking for.